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ABSTRACT 

The  United  States  Marine  Corps  (USMC)  will  be  fielding  the  SINCGARS 
frequency-hopping  radio  system  during  the  next  5  years.  There  will  be  units 
within  the  Corps  during  the  transition  period  in  which  both  the 
conventional  fixed-frequency  radio  and  the  SINCGARS  radio  will  be 
employed  in  the  same  area  at  the  same  time.  The  Marine  Corps 
Communications  Architecture  Analysis  Model  (MCCAAM)  presented  in  this 
thesis  will  give  Marine  Corps  decision  makers,  analysts,  and  communications 
officers  the  ability  to  quantify  the  effectiveness  of  alternative  tactical  radio 
system  configurations  within  a  given  Marine  Air-Ground  Task  Force 
(MAGTF)  environment.  Using  a  unique  traffic  workload  paradigm  to 
generate  realistic  message  traffic,  this  object-oriented  simulation  model 
assesses  the  overall  performance  of  a  given  architecture  with  a  specified  mix 
of  fixed-frequency  and  frequency-hopping  radios  through  a  penalty  accrual 
process  or  through  aggregating  traditional  communications  MOEs.  USMC 
decision  makers  and  communications  officers  can  use  the  results  of  the 
system  performance  rankings  and  associated  sensitivity  trade-off  analysis  to 
determine  where  best  to  allocate  the  new  frequency  hopping  radios,  as  they 
become  available,  in  order  to  maximize  the  overall  FM  communications 
performance  of  a  given  MAGTF. 
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I.  INTRODUCTION 

A.  BACKGROUND 

The  problem  of  commanding  and  controlling  armed  forces,  and  of 
instituting  effective  communications  with  and  within  them,  is  as  old  as 
war  itself.  A  Stone  Age  chieftain  had  to  devise  the  optimal  organization 
and  find  the  methods  and  technical  means  to  command  the  forces  at  his 
disposal.  From  his  day  to  ours,  failure  to  consider  and  to  solve  the 
problem  was  to  court  disaster — indeed,  to  make  it  impossible  for  the 
forces  to  exist.  [Ref.  1] 

Success  in  future  conflicts  at  all  levels  of  intensity  will  depend  on  the 
ability  of  Marine  commanders  to  gather,  store,  display,  and  forward 
information  and  operational  orders  at  a  faster  and  more  efficient  level  than 
ever  required  before.  The  strategic  significance  of  communications  superiority 
lies  in  its  potential  to  create  major  asymmetries  in  the  distribution  of 
information  in  any  given  situation  [Ref.  2].  Recognizing  this,  the  Marine 
Corps  is  moving  toward  automation  by  introducing  computer-based  systems 
and  digital  communications  into  virtually  every  area  of  command  and 
control.  [Ref.  1] 

The  recent  emphasis  on  rapidly  evolving  military  technology  raises  a 
major  issue  for  the  United  States  and,  specifically,  for  the  Marine  Corps.  At 
what  pace  should  we  pursue  the  new  technology,  possibly  at  the  expense  of 
the  full  completion  of  current  or  proposed  programs?  To  answer  this  and 
similar  questions  in  this  time  of  rapidly  changing  technologies  and  limited 
defense  budget,  it  is  more  important  than  ever  for  the  Marine  Corps  to  have 
an  analytical  methodology  and  complementary  modeling  technique  that  can 
quickly  and  thoroughly  compare  and  contrast  new  or  anticipated  tactical 


command,  control  and  communications  (C3)  systems  [Ref.  3].   To  ensure  that 
only  the  most  cost  effective  changes  are  implemented,  the  Marine  Corps 

needs  the  specific  capability  to: 

•  compare  proposed  C3  architectures; 

•  allocate  new  resources  optimally  in  existing  network  structures;  and 

•  appraise  the  change  in  performance  that  will  result  from 
implementing  specific  improvements  in  equipment,  doctrine  or 
training  [Ref.  4]. 

As  part  of  a  needed  modernization  of  its  communication  technology,  the 

Marine  Corps  will  be  fielding  the  SINCGARS  frequency-hopping  radio  system 

as  a  replacement  for  the  VRC-12  family  of  single  channel  radios  during  the 

next  five  to  ten    years.    Over  the  transition  period,  there  will  be  units  in 

which  the  current,  conventional,  fixed-frequency  radios  and  the  SINCGARS 

radios  will  be  employed  in  the  same  geographical  place  at  the  same  time. 

Knowing  that  there  will  not  be  enough  money  in  the  budget  to  totally  replace 

all  the  older  radios  at  one  time,  and  given  an  imperfectly  specified  enemy 

jamming,  interference,  and  interception  capability,  one  of  the  Marine  Corps' 

current  challenges  is  the   allocation  of   the  new  SINCGARS  radios  within  the 

Marine  Air-Ground  Task  Force  (MAGTF)  structure  to  provide  the  most 

reliable,  robust,  and  effective  architectures  possible. 

B.    PURPOSE 

The  purpose  of  this  thesis  is  to  design  and  implement  a  simulation 
model  to  provide  Marine  Corps  decision  makers,  analysts,  and 
communications  officers  the  ability  to  quantify  the  effectiveness  of  alternative 
tactical  radio  system  configurations  within  any  specific  MAGTF 
environment.     The  Marine  Corps  Communication  Architecture  Analysis 


Model  (MCCAAM)  presented  in  this  thesis  uses  a  unique  traffic  workload 
paradigm  to  generate  realistic  network  traffic  and  assesses  the  overall 
performance  of  a  given  architecture  (a  specified  mix  of  fixed-frequency  and 
frequency-hopping  radios)  through  a  penalty  accrual  process  or  through 
aggregating  traditional  communications  MOEs.  This  object-oriented 
simulation  model  will  allow  Marine  Corps  decision  makers  to  determine  the 
best  allocation  of  the  new  frequency  hopping  radios,  as  they  become  available, 
in  order  to  maximize  the  overall  communications  performance  of  a  MAGTF. 
As  an  example  of  how  MCCAAM  can  be  used,  this  thesis  presents  a 
statistical  analysis  of  four  different  SINCGARS  allocation  schemes  that  might 
be  considered  by  the  Marine  Corps.  The  objective  of  this  analytical  example  is 
to  determine  whether  there  is  any  real  difference  in  the  tactical  radio  system 
performance  between  the  different  allocation  schemes,  to  estimate  those 
differences  using  two  different  performance  measuring  approaches,  and  to 
assess  the  precision  of  the  estimates. 

C    OUTLINE  OF  THESIS  CHAPTERS 

Given  the  thesis  background  and  purpose  described  above,  the  first  step 
pursued  in  this  thesis  is  to  completely  describe  and  frame  the  problem  under 
consideration.  Chapter  II  gives  the  necessary  background  information  to 
bound  the  Marine  Corps'  communication  architecture  analysis  problem.  We 
illustrate  the  complexity  and  scope  of  the  problem  by  briefly  describing  the 
unique  communication  needs  presented  by  the  expeditionary  nature  of  the 
various  MAGTF  levels  of  organization.  The  many  factors  that  contribute  to 
the  complexity  of  any  communications  analysis  are  highlighted  by  discussing 
general    Marine    Corps    communication    principles,    equipment,    and 


information  requirements.  This  information  is  important  because  it  drives 
much  of  the  modelling  that  is  implemented.  To  provide  the  necessary 
background  for  the  measures  of  effectiveness  used  in  this  analysis,  the  key 
characteristics  of  the  VRC-12  family  of  radios  currently  in  use  and  the  new 
frequency-hopping  radios  is  presented.  Basically  a  facts  and  figures  section, 
Chapter  II  concludes  with  a  description  of  the  analysis  process  that  was  used 
in  approaching  this  problem. 

Chapter  III  explains  why  simulation  was  used  for  this  analysis  and 
describes  the  key  features  of  object-oriented  simulation  and  how  they  made 
this  approach  the  best  analysis  tool  for  our  problem.  A  brief  argument  is 
given  in  support  of  the  decision  to  use  the  MODSIM  II  language  instead  of  a 
graphically  oriented  product.  Following  the  essential  aspects  of  the  modelling 
language,  the  modular  approach  we  used  in  writing  code  is  described,  and  the 
model  development  phases  are  described  (because  they  were  a  key  part  of  the 
whole  problem  solving  process).  To  provide  a  general  understanding  of  the 
actual  model  used  for  this  analysis,  the  essential  message  traffic  paradigm  is 
presented  and  the  key  module  contents  are  highlighted.  The  way  the  many 
different  modules  interact  during  an  actual  simulation  run  is  presented  next 
as  a  typical  scenario  "flow."  The  chapter  concludes  with  a  discussion  of  the 
model  data  requirements  and  how  they  were  met.  A  reasonable  defense  of 
most  assumptions  is  presented  to  fully  define  those  areas  that  are  not  fully 
addressed  or  modeled.  Model  resolution  is  re-addressed.  Chapter  III  is 
essential  because  it  highlights  the  areas  of  the  model  development, 
implementation,  and  analysis  that  are  not  readily  apparent. 


Chapter  IV  starts  the  transition  from  the  model  to  the  analysis  through  a 
full  discussion  of  measures  of  performance,  measures  of  effectiveness,  and 
measures  of  force  effectiveness.  By  highlighting  the  characteristics  of  the 
desired  MOEs,  a  case  is  made  for  those  specific  MOEs  used  in  the  analysis. 
The  MOE  aggregation  approach  we  adopted  is  discussed  with  advantages  and 
disadvantages  presented.  The  penalty  process  used  to  assess  the  overall 
performance  of  a  given  network  is  described  and  the  accompanying  output 
analysis  is  briefly  highlighted. 

Chapter  V  specifically  ties  the  chosen  MOEs  to  the  actual  simulation  runs 
through  the  experimental  design  that  was  established  to  capture  and  measure 
system  differences  for  our  example.  Also  in  this  chapter,  the  alternate 
SINCGARS  allocation  schemes  are  described  and  we  present  the  way  the 
simulation  model  was  used  to  compare  them. 

Chapter  VI  begins  by  illustrating  how  the  model  output  was  used  to 
verify  the  model.  After  model  verification  is  established,  the  experimental 
results  are  detailed  and  a  claim  is  made  that  the  effectiveness  of  the 
alternative  communications  systems  has  been  sufficiently  quantified.  The 
alternative  communication  system  performance  results  are  presented  in  a 
manner  that  allows  a  decision  maker  to  readily  see  the  origins  and 
significance  of  the  differences.  Before  Chapter  VI  closes  with  a  three  step 
approach  to  model  validation,  we  discuss  the  use  of  variance  reduction 
techniques. 

Finally,  Chapter  VII  recaptures  the  highlights  of  our  model  development 
work  and  its  applicability    to  the    current  Marine  Corps  communications 


analysis  problems.    Concluding  comments  regarding  model  validation  and 
usefulness  are  followed  by  a  discussion  of  potential  model  embellishments. 


II.  PROBLEM  APPROACH  AND  FRAMEWORK 

A.    THE  ANALYSIS  PROCESS 

The  previous  chapter  presented  the  problem  background  and  the  focus  of 

this  thesis.     The  current  section  describes  the  analysis  process  used  in 

approaching  our  problem.    We  accomplish  this  by  focusing  on  the  different 

steps    undertaken    throughout    MCCAAM    model    development    and 

application. 

In  any  analysis  supporting  decisions  during  the  life  cycle  of  a  system,  it  is 
essential  to  be  able  to  relate  the  contribution  of  the  various  alternatives 
under  consideration  to  the  desired  objectives  of  the  system,  or  military 
force.  The  mechanism  by  which  this  relationship  is  established  is 
referred  to  as  "the  analysis  process."  [Ref.  5] 

Proper  selection  of  the  criteria  to  be  used  in  comparing  alternatives  is 
more  an  art  than  a  science  and  is  treated  as  one  of  the  most  important  steps  in 
developing  an  analysis  plan.  Our  ability  to  specify  the  values  of  these  criteria 
heavily  influences  the  efficacy  of  the  analysis  to  accomplish  the  objectives 
defined  during  problem  formulation. 

The  Modular  Command  and  Control  Evaluation  Structure  (MCES) 
developed  by  a  joint  working  group  [Ref.  5]  is  a  general  approach  for 
evaluating  C3  systems  that  has  been  successfully  applied  to  a  number  of  issues 
concerning  C3  systems  planning,  acquisition,  testing  and  operation.  It 
incorporates  all  of  the  previously  mentioned  basic  analysis  activities  in  a 
series  of  seven  steps  or  modules  (Figure  1)  to  evaluate  alternative  C3  systems 
and  architectures.  The  following  paragraphs  describe  how  these  modules 
were  used  as  guidelines  in  developing  and  evaluating  the  MCCAAM  model. 


IMPLEMENT 
RESULTS 


NO  ACTION  TAKEN 


K3H 


1 


PROIJLEM 
ORMULATION 


C2   SYSTEM 
HOUNDING 


I 


C2   PROCESS 
DEFINITION 


T 


INTEGRATION  OF  SYSTEM 
CLEMENTS  AND  FUNCTIONS 


I 


SPECIFICATION  OF 

MEASURES 


I 


DATA 
GENERATION 


I 


AGGREGATION 

OF   MEASURES 


Figure  1.  Modular  Communications  Evaluation  Structure  (MCES) 
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PROBLEM  FORMULATION  MODULE.  In  this  module,  the  Marine  Corps 
decision  makers  were  identified  and  their  objectives  were  described.  Next, 
the  alternatives  for  the  SINCGARS  allocation  problem  were  identified  so  they 
could  be  modelled  in  later  steps,  and  the  various  mission  areas  affected  were 
detailed.  As  a  result,  the  scope  and  depth  of  the  Marine  Corps  analysis  needs 
were  defined  and  basic  assumptions  were  agreed  upon. 

SYSTEM  BOUNDING  MODULE.  Here  the  MAGTF  elements  that  would 
be  affected  by  the  SINCGARS  allocations  were  identified  from  doctrinal 
publications.  C3  system  statics  (units  &  radios)  were  distinguished  from 
system  dynamics  (activities  &  procedures),  and  physical  units  were  defined 
along  with  their  associated  command  structures.  Marine  Corps  standard 
operating  principles  were  investigated  to  provide  needed  guidance  for  proper 
modelling  of  message  durations,  protocols,  and  reporting  requirements. 

PROCESS  DEFINITION  MODULE.  In  this  phase,  the  dynamic  C3 
processes  of  the  Marine  Corps  tactical  FM  radio  networks  were  identified  by 
looking  at  the  functions  of  the  C3  cycle  (sense,  assess,  generate,  select,  plan, 
and  direct)  as  performed  by  the  units  identified  in  the  previous  phase.  Since 
the  SINCGARS  system  is  most  concerned  with  the  conveyance  of  sensed 
information,  plans,  and  direction,  the  model  developed  is  actually  a 
communications  model  more  than  an  overall  C3  system  model.  The 
assessment,  generation,  and  selection  functions  are  not  really  addressed  in 
MCCAAM. 

INTEGRATION  MODULE.  In  this  module,  basic  communications 
functions  (enter  net,  transmit,  receive,  change  frequency,  etc.)  were  mapped  to 
the  command  system  elements  (specific  units  or  command  and  control 


facilities).  In  this  modeling  context,  the  message  traffic  flow  represents  most 
of  this  mapping.  This  integration  is  the  combination  of  the  results  of  steps 
two  and  three:  integrating  the  system  elements  and  the  process  functions 
into  a  valid  simulation  model. 

SPECIFICATION  OF  MEASURES  MODULE.  At  this  stage,  Measures  of 
Effectiveness  (MOEs)  and  Measures  of  Performance  (MOPs)  were  identified 
and  agreed  upon  with  the  Marine  Corps  project  officers.  The  MOEs  selected 
measure  aspects  of  the  communication  system  functions  that  contribute  to 
the  overall  accomplishment  of  critical  missions  while  the  MOPs  quantify 
critical  capabilities  of  the  radios. 

DATA  GENERATION  MODULE.  Here  values  for  the  MOPs  and  MOEs 
were  obtained  from  the  simulation  model  (MCCAAM).  This  is  accomplished 
by  generating  traffic  with  different  rates  of  occurrences.  This  traffic  is 
simulated  as  it  works  through  the  given  force  architecture  where  relevent 
net  and  radio  statistics  are  collected.  Many  simulation  test  runs  under  a 
specific  experimental  design  yield  the  data  ultimately  used  in  our  analysis. 

AGGREGATION  AND  INTERPRETATION  MODULE.  The  numerical 
results  obtained  from  the  simulation  runs  as  MOPs  and  MOEs  were 
aggregated  under  a  scheme  described  in  Chapter  in  to  provide  an  overall 
quantifiable  measure  of  system  effectiveness. 

In  the  SINCGARS  allocation  application,  the  measures  would  ideally  be 
measures  of  force  effectiveness  (MOFEs)  that  reflected  the  effect  better 
communications  had  on  the  outcome  of  battles.  But  the  Marine  Corps 
desired  a  flexible,  scenario-independent  model  which,  of  necessity,  excludes 
battle  outcomes.  Therefore,  measures  of  communications  effectiveness  were 
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selected  in  two  major  categories:  timeliness  of  message  receipt  and  reliability 
of  network  connectivity. 

B.    USMC  MAGTF  STRUCTURE 

To  understand  the  specific  areas  of  our  simulation  model  development  it 
is  necessary  to  understand  the  building  blocks  that  were  used  to  model  the 
MAGTF  communications  architecture.  These  building  blocks  are  the  MAGTF 
force  structure  and  how  units  are  related  organizationally,  the 
communications  principles  dictating  how,  when,  and  why  units 
communicate,  and  the  physical  equipment  that  is  used  to  actually  establish 
the  essential  communication  lines.  Figure  2  [Ref.  5]  illustrates  how  these 
building  blocks  exist  within  a  framework  that  contains  not  only  the 
equipment  sub-systems,  but  the  forces  and  environment  as  well. 
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Figure  2.  Communication  System  Bounding 
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This  section  briefly  discusses  these  building  blocks  as  motivation  for  how 
and  why  our  model  was  developed  the  way  it  was. 

A  Marine  Air-Ground  Task  Force  (MAGTF)  is  the  organizational 
structure  used  for  nearly  all  operations  conducted  by  United  States  Marine 
Corps  forces.  Independent  of  the  size  of  the  force,  MAGTFs  are  combined 
arms  organizations  composed  of  a  command  element,  a  ground  combat 
element,  an  aviation  combat  element,  and  a  combat  service  support  element 
(See  Figures  3  &  4). 


Command 
Element 

1 
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\ 

' 

\ 1 

Aviation  Combat 
Element 

Ground  Combat 
Element 

Combat  Service 
Support  Element 

Figure  3.  MAGTF  Element  Sizes 

In  order  to  support  combined  air,  ground  and  logistics  operations,  four  (or 
more)  distinct  command  and  control  systems  which  differ  in  degree  of 
centralization,  automation,  mobility,  and  complexity  must  be  integrated. 
These  distinct  systems  are  composed  of  heterogeneous  links  and  widely 
shared  network  resources  which,  when  combined,  form  the  key  neurological 
component  of  a  MAGTF.   [Ref.  11] 

The  three  sizes  of  operational  MAGTF's  are  the  Marine  Expeditionary 
Unit,  Marine  Expeditionary  Brigade,  and  Marine  Expeditionary  Force  (MEU, 
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MEB,  MEF).  From  the  smaller,  more  mobile  MEU  to  the  massive  MEF,  these 
MAGTFs  are  formed  for  specific  operational  requirements  from  various 
available  units  as  illustrated  in  Figure  4. 


ACE 

GCE 

CSSE 

MEU 

Squadron 

Battalion 

CSSD 

MEB 

Group 

Regiment 

BSSG 

MEF 

Wing 

Division 

FSSG 

Figure  4.  MAGTF  Element  Sizes 

The  purpose  of  system  bounding  (third  step  in  the  MCES  process)  is  to 
explicitly  define  the  organizational  scope  of  the  problem.  The  result  of  this 
problem  scoping  step  are  lists  or  tables  of  the  physical  elements  and  structures 
that  enumerate  the  levels  of  the  problems.  The  complete  list  of  all  units 
involved  in  this  specific  MEB  analysis  is  provided  in  Appendix  D. 

The  system  of  focus  is  the  MEB  C3.  The  conceptual  name  for  this  system 
is  the  Marine  Corps  Tactical  Command  and  Control  System  (MTACCS).  It 
consists  of  the  people,  the  hardware,  and  the  software  systems  in  the 
operational  headquarters  or  command  and  control  facilities  (C2FACs)  of  the 
MEB.  There  are  subsystems  of  the  MTACCS  for  ground  C3,  aviation  C3, 
combat  service  support  (CSS)  C3,  and  intelligence.  Table  1  shows  some  of  the 
major  systems  under  each  of  these.  Some  of  these  are  currently  under 
development  while  others  are  in  place.  The  communications  elements  of 
these  systems  are  represented  in  the  Marine  Corps  Tactical  Communications 
Architecture  overview  chart  which  cannot  be  reproduced  at  this  scale  but 
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which  would  be  familiar  to  anyone  involved  in  Marine  Corps  C3  discussions. 
[Ref.  18] 

TABLE  1.  EXAMPLE  MTACCS  SYSTEMS 

Ground  C2  System 

Tactical  Combat  Operations  (TCO) 
Fireflex  System 

Aviation  C2  System 

Advanced  Tactical  Air  Command  and  Control  Central  (ATACC) 
Tactical  Air  Operations  Module  (TAOM) 

Combat  Service  Support  System 

Marine  Integrated  Personnel  System  (MIPS) 

Logistics  Automated  Information  System  (LOGISTATS) 

Intelligence  System 

Tactical  Electronic  Reconnaissance  Process  and  Evaluation  System 
(TERPES) 

MCCAAM  is  currently  being  used  to  analyze  only  the  ground  C3  systems, 

but  by  design  it  can  easily  be  modified  and   enlarged  to  incorporate  aviation 

and  combat  service  support  systems  that  are  key  parts  of  a  complete  MEB 

communications  architecture.    Figure  5  [Ref.  17]  provides  another  view  of 

MCCAAM's  current  scope — the  tactical,  voice  radio  systems. 

C    MAGTF  COMMUNICATIONS 
1.     General 

A  command  and  control  system  is  defined  [Ref.  6]  as  consisting  of  the 
facilities,  equipment,  communications,  procedures,  and  personnel  essential  to 
a  commander  for  planning,  directing,  coordinating  and  controlling 
operations  of  assigned  forces  pursuant  to  the  missions  assigned.  The 
functions  of  this  system  are  to: 
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Figure  5.  MAGTF  Communications  Systems 

•  Provide  the  commander  accurate  and  timely  information  and  ideas  for 
developing  courses  of  action  and  making  decisions. 

•  Translate  the  commander's  decisions  into  plans  and  orders. 

•  Communicate  those  plans  and  orders  to  subordinates. 

•  Provide  required  information  to  and  respond  to  tasking  from  higher 
and  supported  commands. 

To  build  a  simulation  model  of  a  MAGTF  tactical  communications 

network  in  all  of  its  dynamics,  it  was  first  necessary  to  understand  all  the 

mathematical  model  underpinnings  that  would  be  used  to  structure  the 

simulation  process.   First,  a  brief  discussion  of  the  communications  process  is 
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presented.  This  process  must  be  understood  to  effectively  model  any 
communications  architecture. 

Each  unit  within  a  MAGTF  possesses  specified  radio  resources  which 
individually  compete  for  transmission  time  over  their  assigned  nets.  Over 
time,  each  radio  receives  messages  which  are  classified  according  to  priority, 
and  higher  priority  traffic  usually  gets  transmission  precedence.  When  the 
respective  radio  operators  receive  written  messages  to  be  transmitted  to 
higher,  subordinate  and  adjacent  units,  they  wait  until  the  tactical  net  is  free 
of  traffic  and  then  attempt  to  reach  the  receiving  units  with  their  highest 
priority  message.  If  a  radio  operator  receives  messages  of  the  same  priority, 
he  usually  transmits  them  in  the  order  he  receives  them.  This  discipline  is 
commonly  referred  to  as  store-and-forward  switching.    [Ref.  32] 

Delay  of  the  messages  may,  in  practical  military  networks,  vary  from 
a  fraction  of  a  second  to  several  hours,  measured  from  the  time  the  message 
is  first  received  by  the  initial  radio  operator.  This  delay  consists  of  the  times 
for  the  unit  operators  to  store  and  retrieve  the  message  along  the  various 
links,  the  times  that  the  message  sits  in  storage  queues  at  the  unit  nodes 
waiting  for  the  net  to  become  available,  and  the  often  extensive  time  required 
to  just  make  radio  contact  with  the  intended  receiver.  The  first  types  of  delays 
(node  processing  and  net  transmission)  can  be  made  relatively  small  in  digital 
communications  relative  to  the  maximum  tolerable  delay.  In  voice 
communications,  the  net  transmission  time  is  often  much  larger.  The  unit- 
to-unit  message  delay,  which  is  typically  the  principal  criterion  of 
performance,  depends  largely  on  the  queuing  delays  at  the  various  units. 
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Modelling  all  forms  of  these  delays  is  a  central  focus  of  our  programming 
effort.  [Ref.32] 

Given  the  communications  problem  stated  above,  it  was  natural  to 
approach  our  modelling  task  from  the  queueing  theory  perspective  where  a 
large  number  of  alternative  mathematical  models  have  been  produced  for 
various  waiting  line  situations.  We  initially  focused  on  the  single  unit 
queuing  system  and  then  branched  out  to  model  the  entire  communication 
architecture  as  a  network  of  queues. 

The  operating  characteristics  of  queuing  systems  are  determined  by 
two  key  distributions:  the  probability  distributions  of  the  inter-arrival  times 
and  of  the  service  times.  To  build  a  simulation  model  as  a  representation  of 
the  real  tactical  communication  system  we  were  interested  in,  it  was  first 
necessary  to  specify  the  assumed  form  of  these  two  key  distributions.  To  be 
useful  in  any  form,  the  assumed  distributions  had  to  be  sufficiently  realistic 
so  that  the  model  provides  reasonable  predictions,  while  at  the  same  time 
being  feasible  to  work  with.  A  discussion  of  the  distributions  used  to  provide 
randomization  in  MCCAAM  is  provided  in  section  C  of  Chapter  HI. 
2.     Communications  Principles 

This  section  addresses  MAGTF  command,  control  and 
communication  principles  applicable  to  operation  of  communications  and 
computers  in  task  forces  at  all  levels  of  warfare.  This  material  is  presented  to 
motivate  and  explain  the  Measures  of  Effectiveness  (MOEs)  selected  and  to 
illustrate  the  type  of  information  that  was  considered  during  the  modelling 
process.  To  build  a  communications  architecture  which  will  serve  the  needs 
of  a  wide  variety  of  users  and  communications  managers,  it  is  essential  that 
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the  complex  communications  possible  with  today's  technology  be  guided  by 
fundamental  doctrine.  Nearly  all  of  the  principles  which  follow  have  been 
drawn  verbatim  from  doctrinal  publications  and  are  categorized  into  two 
categories:  those  applicable  to  organizations  and  those  inherent  in  the 
communications  process.  [Ref.8] 

Principles  applicable  to  organizations  [Ref.  7:  par  1008]  are  essentially 
rules  of  the  road.  They  state  which  commander  has  the  responsibility  for 
establishing  and  maintaining  communications  when  units  work  together. 
Since  these  are  conventions  established  to  place  responsibility,  no  elaboration 

is  necessary. 

•  Communications  between  a  senior  and  subordinate  unit  are  the 
responsibility  of  the  senior  commander. 

•  Communications  between  adjacent  units  are  the  responsibility  of  the 
first  common  senior  commander. 

•  Communications  between  a  supporting  and  supported  unit  are  the 
responsibility  of  the  supporting  unit  commander. 

•  Communications  between  a  unit  and  an  attached  unit  are  the 
responsibility  of  the  unit  to  which  the  attachment  is  made. 

Principles  applicable  to  the  communications  process  that  were 

considered  in  modeling  the  MAGTF  C3  architecture  and  which  are  important 

to  MOE  selection  are  the  following  [Ref.  7:  par  1004, 1005]: 

•  Communications  must  be  reliable.  Communications  which  enable  a 
commander  to  plan,  direct,  coordinate  and  control  forces  in  combat 
must  be  fully  dependable  and  accurate.  Reliability  is  attained  through 
dependable  equipment,  excellent  planning  and  execution  techniques, 
and  first  class  communications  training  of  all  personnel. 

•  Communications  must  be  secure  from  all  except  intended  recipients. 
All  unauthorized  persons  and  organizations  must  be  denied 
information  about  a  command's  activity  and  status.  This  results  in  an 
enhanced  operational  security  (OPSEC)  posture  and,  at  the  same  time, 
denies  the  enemy  information.     Security  includes  safeguarding  the 
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physical    equipment,    documents,    and    personnel    as    well    as    the 
cryptographic,  transmission,  and  emission  security. 

•  Communications  must  be  timely.  Command  and  control 
communications  must  arrive  at  the  intended  user's  location  in  time  to 
be  made  useful.  Speed  of  communications  refers  not  only  to  the  ability 
of  hardware  to  transmit  and  receive  data,  but  to  the  use  of  efficient 
methods  and  procedures. 

•  Communications  must  be  flexible.  FMFM  3-30  states  that  "Flexibility  is 
the  ability  to  support  wide  dispersion  of  units  under  adverse  and 
varying  conditions.  A  flexible  communications  system  is  achieved  by 
detailed  advanced  planning,  anticipation  of  the  commander's  needs, 
and  provisions  for  the  installation  and  maintenance  of  a  responsive 
communications  system." 

•  Communications  must  be  interoperable.  For  communications  systems 
to  transfer  data  successfully,  it  is  obviously  essential  that  message 
standards,  protocol  standards,  and  data  standards  be  established  and 
adhered  to. 

•  Communications  systems  must  be  mobile.  Combat  operations, 
especially  Marine  Corps  offensive  combat,  requires  rapid  maneuver  of 
forces.  A  communications  system  must  be  capable  of  full  support  of 
force  maneuver.  The  amount  of  time  involved  in  the  set-up  and 
establishment  of  a  network  is  an  important  factor  of  this  criteria. 

•  Communications  systems  must  be  survivable.  Vital  to  the  maneuver 
of  forces,  communications  must  be  invulnerable  to  interruption  on 
any  battlefield  and  at  any  level  of  warfare.  Inherent  in  this  criteria  is 
the  need  for  a  communications  system  to  be  able  to  operate  in  the 
midst  of  jamming,  interference,  direction  finding  and  other  enemy 
electronic  activities. 

•  Communications  must  be  economical. 

•  Communications  must  be  simple.  Simplicity  promotes  smooth, 
efficient  operation  for  users  and  communications  personnel  who  must 
establish,  maintain  and  use  systems.  Even  though  the  technical  aspects 
of  communications  systems  become  complex,  it  is  essential  to  keep 
procedures  and  techniques  as  simple  as  possible  in  order  to  meet  the 
objectives  of  the  command  and  control  system. 

3.     Characteristics  of  FM  Voice  Transmission 

Within  the  infantry,  artillery,  and  mechanized  units  of  a  Marine 
Corps  MAGTF,  the  primary  method  of  communications  between  elements  is 
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typically  single-channel,  frequency  modulated  (FM)  radios  utilizing  voice 
transmission.  While  this  mode  is  easy  to  use,  reliable,  and  fast,  it  does  suffer 
from  certain  limitations.  U.S.  Marine  Corps  tactical  FM  radios  generally 
operate  in  the  frequency  range  of  30  to  76  megahertz  (MHz)  with  typical 
output  powers  ranging  from  3-5  watts  in  portable  man-packed  radios  to  33 
watts  for  the  vehicular  radios.  Since  radio  waves  above  30  MHz  primarily 
travel  by  line-of-sight  paths  and  since  power  outputs  of  3  to  33  watts  are  not 
high,  these  radios  are  generally  reliable  only  for  short  distance  transmissions. 
Also,  single  channel  tactical  FM  radio  equipment  is  characteristically  half 
duplex.  That  is,  all  tactical  radios  are  push-to-talk  and  release-to-listen  radios. 
They  can  only  transmit  or  receive,  but  not  both  at  the  same  time.  When  only 
one  station  transmits  a  message  on  a  given  frequency  at  a  time,  assuming  that 
no  jammers  are  active  and  an  acceptable  propagation  path  exists,  then  any 
station  within  range  of  that  transmitter  will  receive  its  transmissions.  If, 
however,  two  or  more  stations  attempt  to  transmit  simultaneously  on  the 
same  frequency,  interference  may  occur  and  the  receiving  stations  may  not  be 
able  to  discern  the  intended  signals.  Furthermore,  FM  radios  tend  to  capture 
the  strongest  signal  transmitted  on  their  respective  listening  frequencies. 
This  characteristic,  known  as  FM  capture,  tends  to  make  single  channel  radios 
very  susceptible  to  jamming.  [Ref.  10] 

Based  on  the  limitations  and  characteristics  of  FM  radios  discussed 
above,  the  following  simplifying  assumptions  were  made  for  this  model  and 

analysis: 

•      Transmissions  under  way  in  a  net  will  not  be  interrupted  by  other 
stations  in  the  net  desiring  to  use  the  net. 
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•  When  a  message  is  transmitted  over  a  net,  all  stations  that  receive  the 
message  will  interpret  that  message  correctly.  This  assumption  is  that 
human  error  in  interpretation  is  negligible. 

The  human  factors  being  assumed  away  are  not  trivial  but  are  so 
complex  that  attempts  to  simulate  them  would  detract  from  the  overall 
modelling  effort.     Proper  training  and  motivation  of  radio  operators  will 
eliminate  much  of  the  human  factor  problems  [Ref.  9:pp.  17-18]. 
4.     The  Commander's  Critical  Information  Requirements 

To  further  motivate  the  structure  and  background  of  our 
communications  model,  this  section  highlights  the  necessity  for  a  dependable 
C3  architecture  that  processes  traffic  in  a  timely  manner.  We  then  present  an 
overview  of  how  current  technology  is  being  used  to  achieve  these  goals  in 
military  communications.  It  is  our  intent  that  the  MCCAAM  model  will  be 
expanded  to  test  and  predict  the  impact  of  some  of  these  current  changes. 

Fundamental  to  any  discussion  of  command,  control,  and 
communications  is  the  commodity  of  information.  Since  time  is  always 
working  against  the  commander's  ability  to  analyze  information  for  the 
purpose  of  decision  making,  the  keystone  of  any  successful  command  and 
control  system  is  an  efficient  communications  backbone.  "On  today's 
battlefield,  the  ability  of  a  commander  to  pass  information  among  his  forces  is 
critical  to  the  outcome  of  any  engagement  [Ref.  7]."  Given  this  truth,  our 
model  structures  and  measures  of  effectiveness  are  highly  time  sensitive. 

In  amphibious  operations,  the  single  channel  radios  (SCRs)  are  the 
principal  means  of  communication  during  the  assault  phase.  SCR 
configurations  supporting  high  frequency  (HF),  very  high  frequency  (VHF), 
and  ultra  high  frequency  (UHF)  communications  are  found    throughout  all 
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elements  of  a  MAGTF.  Though  these  radios  have  been  designed  and 
traditionally  used  for  voice  communications,  computer  technological 
advancements  have  introduced  the  capability  to  transmit  computer-generated 
information,  such  as  a  situation  report  typed  on  a  word  processor,  over 
tactical  radio  systems. 

A  significant  advantage  of  computer-to-computer  communications 
instead  of  voice  is  the  speed  of  information  that  is  transferred  and  the  fact 
that  operator  intervention  is  kept  to  a  minimum.  For  example,  in  the  time  it 
takes  one  to  read  this  paragraph,  an  entire  Size,  Activity,  Location,  Unit, 
Time,  Equipment  (SALUTE)  report  of  over  300  words  can  be  transmitted. 
This  ability  to  transmit  high  volumes  of  information  in  a  short  time  is  called 
burst  transmission,  and  time  on  the  air  is  significantly  reduced  with  this 
capability.  Consequently,  the  opportunity  for  the  enemy  to  successfully  locate 
a  position  is  minimized.  [Ref.  1] 

As  the  Marine  Corps  and  other  services  continue  to  incorporate 
technological  advances  like  digital  communications  terminals  (DCTs)  and 
packet  radio  modems  in  their  communications  architectures,  it  will  be 
essential  that  the  services  have  the  means  to  assess  their  contribution  to  the 
overall  communication  system  performance.  Though  not  currently 
modelling  these  aspects  of  modern  military  communication,  MCCAAM  can 
be  easily  modified  to  test  the  effects  of  such  technology  on  a  given 
architecture's  message  throughput,  efficiency,  and  resistance  to  intervention. 

C    SINCGARS/VRC-12  CHARACTERISTICS 

This  section  provides  the  reader  with  a  general  description  of  the  physical 
characteristics  and  functional  parameters  of  the  current  AN/VRC-12  and 
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AN/PRC-77  radios  compared  to  the  SINCGARS-V  replacement 
configurations.  The  differences  between  the  two  radio  technologies  affect  the 
overall  FM  communication  system  performance,  and  thus  serve  as  the 
foundation  for  the  subjective  MOE  assessments  presented  in  Chapter  IV.[Ref. 
10] 

1.     Conventional  Fixed-Frequency  Radios 

a.  General 

The  AN/VRC-12  series  radio  and  AN/PRC-77  family  radio  are 
the  primary  radios  in  current  use  by  the  U.S.  Marine  Corps  for  the  VHF-FM 
tactical  communications.  Throughout  the  remainder  of  this  thesis,  the  phrase 
"conventional,  fixed-frequency  radio"  will  pertain  to  these  two  types  of  radios 
currently  employed  by  the  Marine  Corps. 

b.  Capabilities 

The  radio  sets  in  the  AN/VRC-12  family  are  short-range, 
vehicular  radio  sets.  The  AN/PRC-77  is  a  compatible,  short  range,  man- 
packed  radio.  These  radios  provide  FM  voice  and  telephone  (MUX) 
communications  and  can  be  used  with  secure  voice  and  digital  data 
equipment.  Two  of  the  sets  (VRC-45  and  VRC-49)  have  re-transmission 
capability.  The  radio  sets  of  the  AN/VRC-12  family  are  used  in  nets  with  the 
AN/PRC-77  radio  sets  within  the  30.00  to  75.95  MHz  frequency  range.  The 
conventional  radios  are  capable  of  transmitting  and  receiving  on  one  of  920 
frequency  channels  separated  by  50  KHz,  and  have  a  planning  range  of  8  to  41 
kilometers.  Range  depends  on  power  out,  antenna  type  and  height  and 
terrain /atmosphere  conditions. 
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c.     Establishing  a  Fixed-Frequency  Net 

The  radio  links  established  between  designated  radio  stations  can 
be  categorized  as  a  broadcast  communication  network.  Each  radio  station  is 
attached  to  a  transmitter/receiver  that  communicates  over  a  medium  shared 
by  other  stations.  All  radio  stations  that  are  tuned  to  the  same  channel  and 
that  are  within  transmission  range  of  each  other  will  be  able  to  receive  a 
broadcast  from  a  transmitting  station.    Two  observations  are  in  order  for 

broadcast  communications  networks: 

•  Since  the  transmission  medium  is  shared,  only  a  single  station  can 
successfully  transmit  at  a  time.  This  requires  some  mechanism  for 
controlling  access  to  the  shared  channel.  The  net  control  station  (NCS) 
offers  a  centralized  scheme  of  control.  The  NCS  can  direct  that  a  "free 
net"  be  established  which  is  also  known  as  the  ALOHA  access  control 
technique.  The  ALOHA  method  is  a  first  come,  first  served  process. 

•  Establishment  of  radio  links  is  limited  by  the  nature  of  the  broadcast 
medium.  The  weather,  terrain,  and  link  distance  affect  the  signal 
transmission  loss  between  stations  in  the  broadcast  communications 
network. 

To  establish  a  radio  net  with  the  conventional,  fixed-frequency  radios,  the 

operator  of  a  radio  set  must  first  locate  his  designated  frequency  in  a 

Communications-Electronics  Operation  Instruction  (CEOI).    The  frequency 

changes  once  every  12  hours.    The  operator  then,  using  the  lowest  power 

setting  available  (to  prevent  unwanted  transmission  range /exposure  to 

enemy  listening  or  DF  devices),  makes  radio  voice  contact  with  the  net 

control  station  (NCS),  asks  permission  to  enter  the  net,  authenticates,  and 

waits  for  instructions  from  the  NCS.     The  NCS,  when  given  a  correct 

authentication,  grants  the  operator  permission  to  enter  the  net,  and  informs 

the  operator  of  net  procedures  (if  any  special  ones  exist).   The  NCS  can  either 

establish    a    directed    net    where    the    radio   operator    must   make    all 
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communication  links  through  the  NCS,  or  a  free  net  can  be  established  where 
any  station  in  the  net  can  call  any  other  station  in  the  net  without  going 
through  the  NCS.  [Ref.  10] 

2.     SINCGARS-V  Frequency-Hopping  Radio 

a.  General 

SINCGARS-V  is  scheduled  to  replace  some  of  the  USMC 
configurations  of  the  AN/PRC-77  and  AN/VRC-12  family  radios  over  the 
next  five  years.  Limited  by  a  budget  that  is  traditionally  very  "tight,"  the 
Marine  Corps  does  not  have  the  luxury  of  replacing  all  the  older  radios  at  one 
time,  though  that  is  understood  to  be  the  eventual  goal.  With  obvious 
emphasis  on  providing  for  the  combat  arms  first,  the  infantry,  armor,  and 
artillery  units  will  receive  the  first  SINCGARS  radios.  See  page  21  of  [10]  for 
the  nomenclatures  of  the  SINCGARS-V  radio  configurations  which  are 
scheduled  to  replace  the  conventional,  fixed-frequency  radios.  This  new  radio 
will  serve  as  the  main  tactical  voice  radio  for  the  MAGTF  when  fully 
allocated,  and  therefore  will  be  critical  to  successful  operations  ashore.  As 
mentioned  previously,  since  there  will  not  be  a  total  one-time  replacement 
of  the  older  radios,  there  will  be  many  situations  over  the  next  few  years 
when  conventional  radios  and  SINCGARS  will  be  operating  in  the  same  area. 
Though  not  discussed  in  this  thesis,  this  will  undoubtedly  provide  many 
interoperability,  maintenance,  and  supply  challenges. 

b.  Capabilities 

SINCGARS  is  a  VHF-FM  radio  system,  electronically  tuned  and 
controlled,  which  operates  in  the  30  to  88  MHz  frequency  band.  It  is  able  to 
transmit  analog  voice,  tactical  analog  data,  and  16  kilobit-per-second  digital 
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data  record  traffic.  The  transmission  range  for  SINCGARS  is  similar  to  that 
of  the  AN/VRC-12  family  radios.  This  new  system  provides  approximately 
2320  discrete  channels  in  the  VHF  spectrum  compared  to  the  920  provided  by 
the  current  radios.  It  can  be  configured  in  man-pack,  vehicular,  and  airborne 
versions  and  it  features  operational  upgrades  through  various  means  to 

include: 

•  Push  button  tuning  via  keyboard 

•  Single  Channel  to  frequency  hopping  by  single  switch  operation 

•  Automatic  identification  of  voice  or  data 

•  LED  display  provides  comprehensive  status  information 

The  SINCGARS  is  lighter  and  about  half  the  size  of  its  current 
counterparts  (See  Figure  6  for  a  summary  of  technical  characteristics).  Some 
models  of  SINCGARS  have  a  re-transmission  capability  similar  to  that  of  the 
present  system  that  uses  two  receiver-transmitters  in  a  special  configuration 
to  transmit  to  units  out  of  normal  communications  range. 

The  primary  ECCM  (Electronic  Counter-Counter  Measures) 
technique  for  SINCGARS  is  its  ability  to  frequency  hop.  An  ECCM  device  can 
be  fixed  to  the  radio  to  give  it  six  ECCM  channels  in  addition  to  two  fixed- 
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SYSTEM  SPECIFICATIONS: 

Frequency  Range 

30.00  to  87.975  MHz 

Modulation  type 

Frequency  modulation  (binary  or  analog)  10  Hz  to  8.0  kHz 

Channels 

2320 

Channel  spacing 

25  kHz 

Modes  of  operation 

Single  channel  and  frequency  hopping 

Preset  channels 

6  for  single  channel  operation 

Frequency  Hopping  Preset  Radio  Nets 

6  each  from  front  panel  selector  switch 

Frequency  Offset  Capability 

±  5  and  ±  10  kHz  to  any  manual  or  preset  frequency 

Frequency  Entry 

Through  the  keyboard 

Frequency  Stability 

±  5.0  PPM 

Communications  Security  Capability 

Will  operate  with  current  US  inventory  COMSEC  equipment 

Digital  Capability 

16  kbps  and  FSK  (with  optional  data  rate  adapter) 

Self  Test 

Microprocessor  controlled  in  conjunction  with  LCD  display 

Radio  tuning 

All  electronic 

■ECEIVER  CHARACTERISTICS: 

Noise  Figure 

10  dB 

Image  Rejection 

80  dB  minimum 

IF  Rejection                       ' 

100  dB  minimum 

Audio  output 

50  mW  or  1  mW/150  ohms  (selectable) 

TRANSMITTER  CHARACTERISTICS: 

Power  output 

10  watts  nominal 

Harmonic  suppression 

MIL-STD-461A 

Transmitter  spurious  responses 

100  dB 

Frequency  deviation 

±  6.5  kHz 

'NPUT  POWER: 

Primary  Power 

+28  Vdc  per  MIL-STD-704  (3.5  Amps  Max.) 

Lighting 

0-115  Vac  400  Hz  (Electroluminescent) 

ENVIRONMENTAL: 

Specification 

MIL-E-5400  Class  IA 

:MTERFACE  CHARACTERISTICS: 

Interfaces  with  the  following  Avionics  equipment: 

•  CV-3885/ARC-201  Data  Rate  Adapter 

•  KY-58.  Z-AHQ.  Z-AHP  COMSEC  Equipment 

•  ID-1351A  Homing  Meter 

•  C-1611,  C-6533,  C-10414  Intercoms 

•  AM-7189A/ARC  50-Watt  Power  Amplifier 

Figure  6.  SINCGARS  Technical  Characteristics 
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frequency  channels.  The  system  uses  a  number  of  separate  frequencies,  and 
one  channel  is  established  by  synchronizing  the  transmission  and  reception 
of  these  frequencies.  The  frequencies  to  which  the  signal  can  be  hopped  can 
follow  an  ordered  or  random  sequence  called  a  hop  set. 

The  band-width  is  increased  due  to  the  use  of  a  multiple  number 
of  frequencies  per  channel.  More  users  can  operate  within  the  same  band 
employing  this  technique  since  they  are  only  on  one  specific  frequency  for  a 
very  short  period  of  time.  Though  there  have  been  several  proposals  for 
different  algorithms  to  deal  with  this  problem,  assignment  of  these 
frequencies  remains  a  difficult  challenge.  [Ref.  10] 

The  SINCGARS  radio  system  is  interoperable  with  the  current 
inventory  of  radios  in  both  the  plain  text  and  cipher  modes  on  a  single  fixed 
channel.  Communications  security  (COMSEC)  equipment  will  be  internal  or 
external  to  the  radio  system  and  both  are  compatible  with  the  current 
radio /COMSEC  configurations. 

Some  additional  features  of  the  SINCGARS  radio  are  [Ref.  10]  : 

Balanced  nuclear  hardening  to  include  Electromagnetic  Pulse  (EMP) 
and  Transient  Radiation  Effects  on  Electronics  (TREE)  protection. 

Modular    components    which    provide    commonality    among    all 
configurations. 

A  high  power  amplifier  (HPA)  module  used  with  the  SINCGARS  to 
provide  a  power  output  of  50  watts. 

Any  one  of  six  frequency  pre-sets  may  be  switch-selected  by  the 
operator. 

Built-in-test  (BIT)  unit  to  detect  failures  in  equipment  modules  or 
cards. 
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c.      Establishing  a  Frequency-Hopping  Net 

Similar  to  the  current  radio  system,  a  broadcast  communication 
network  will  be  used  to  establish  the  frequency-hopping  SINCGARS  radio 
nets.  However,  the  procedures  for  establishing  the  SINCGARS  radio  nets  is  a 
much  more  complicated  process,  as  described  below. 

The  technical  characteristics  of  the  frequency-hopping  radio 
requires  multi-frequency  management  on  a  decentralized  basis.  As  a  result, 
the  procedures  required  to  establish  a  radio  net  become  much  more 
complicated.  The  NCS  must  distribute  five  variables  required  for  frequency- 
hopping  operation  to  each  radio  station  in  the  net.    The  required  variables 

are: 

TRANSEC  Key 
Hopset/Net  ID 
ERF  Frequency 
Cueing  Frequency 
Mission  Day  /Time  of  Day 

A  battlefield  electronic  CEOI  system  (BECS)  electronic  notebook  is  used  to 

generate,  store,  display,  or  transfer  the  five   variables  required  for  SINCGARS 

frequency-hopping  net  operation  to  the  radio  sets.  [Ref.  10] 

There  are  two  methods  for  loading  the  data  into  the  radio  sets. 

The  NCS  can  use  either  a  local  fill  procedure  or  an  electronic  remote  fill 

(ERF).    A  local  fill  procedure  is  accomplished  by  physically  connecting  an 

ECCM  fill  device  or  a  tape  to  the  radio  while  electronic  remote  fill  is 

performed  by  electronically  transmitting  frequency  hopset  variables  between 

SINCGARS  radios.  (Since  much  of  the  data  needed  by  SINCGARS  is  based  on 

the  time  of  day  variable  mentioned  above,  any  inconsistency  in  the  filling 
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procedure  can  lead  to  a  rather  time  consuming  set-up  time  for  a  tactical 
SINCGARS  net). 

In  summary,  the  existing  VRC-12  radios  are  not  as  flexible  and 
reliable  as  the  new  SINCGARS  radios,  but  they  are  simpler  to  set  up  and  use. 
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in.  SOLUTION  METHODOLOGY 

Working  from  our  problem  framework  outlined  in  the  previous  chapter, 
Chapter  III  explains  how  the  MAGTF  structure,  communications  principles, 
and  equipment  were  incorporated  into  our  model  development.  We  begin  by 
giving  our  rationale  for  choosing  simulation  as  the  appropriate  modeling 
tool,  and  then  briefly  discuss  our  choice  of  a  simulation  language.  The  key 
sub-models  of  MCCAAM  are  then  presented  as  a  preliminary  to  describing 
the  overall  simulation  flow.  We  detail  how  messages  are  handled  within  the 
simulated  communications  architecture  to  show  the  reader  the  key  logic  that 
allows  for  accurate  analysis  of  alternative  architectures.  This  chapter 
concludes  with  a  description  of  the  model's  data  input  requirements  and 
assumptions. 

A.    WHY  SIMULATION? 

A  subjective  allocation  of  SINCGARS  radios  could  be  made  by  asking 
experienced  officers  to  review  existing  architectures  and  traffic  requirements 
and  then  allocate  the  available  SINCGARS  radios  to  the  VHF  networks  that 
need  them  most  (highest  traffic  and  most  vulnerability).  However,  even 
experienced  officers  would  have  difficulty  comparing  the  operational 
tradeoffs  offered  by  different  allocations  and  determining  how  the  various 
nets  would  actually  perform  in  different  environments.  Therefore,  a 
quantitative  model,  such  as  discussed  in  this  Chapter,  is  desirable.  [Ref.  18] 

Over  time,  much  effort  has  been  expended  evaluating  the  performance  of 
military  organizations'  communication  systems.   Typically,  these  efforts  have 
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involved  modelling  the  workload  the  communications  system  must  handle. 
The  performance  is  evaluated  using  analytic,  approximation,  Monte  Carlo,  or 
system  simulation  methods.  To  a  large  degree,  the  following  aspects  of  a 
model  are  dictated  by  the  degree  to  which  the  workload  model  reflects  reality 

[Ref.  11]: 

•  the  choice  of  evaluation  technology, 

•  the  development  and  implementation  costs,  and 

•  the  degree  of  acceptance  and  usability  of  the  end  product. 

One  of  the  main  strengths  of  the  analytical  approach  is  that  it  abstracts  the 
essence  of  the  problem  and  reveals  its  underlying  structure,  which  provides 
insight  into  the  cause-and-effect  relationships  within  the  system.  These 
methods  attempt  to  find  and  solve  mathematical  equations  in  a  closed  form 
solution  to  accurately  describe  the  behavior  of  a  system  under  different 
circumstances.  If  it  is  possible  to  construct  an  analytical  model  that  is  both  a 
reasonable  idealization  of  the  problem  and  amenable  to  solution,  this 
approach  is  usually  superior  to  simulation.  However,  many  problems  are  so 
complex  that  they  cannot  be  solved  analytically.  This  is  because  these  systems 
(including  C3  systems)  are  composed  of  a  variety  of  subsystems  that,  even 
when  viewed  individually,  are  extremely  difficult  to  analyze  by  conventional 
methods.  Additionally,  the  choice  of  MOEs  often  drives  us  to  use  simulation, 
independent  of  the  system's  complexity. 

If  a  conventional  approach  is  pursued  to  keep  the  problem  within  a 
tractable  domain,  assumptions  must  be  made  that  could  distort  the  physical 
reality  of  the  system.  Simulation  is  a  versatile  tool  that  is  typically  used  when 
the  system  involved  is  too  complex  to  be  analyzed  satisfactorily  by  analytical 
models.  [Ref.  12] 
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With  this  in  mind,  we  view  simulation  as  a  controlled  statistical 
sampling  technique  for  estimating  the  performance  of  a  complex  stochastic 
communications  system.  We  simulate  the  actions  of  the  communications 
system  over  time  and  record  its  aggregate  behavior  to  estimate  performance. 
We  understand  and  want  to  make  clear  that  "simulation  is  inherently  an 
imprecise  technique  that  provides  only  statistical  estimates  rather  than  exact 
results.  It  compares  alternatives  rather  than  generating  an  optimal  one."  [Ref. 
13:pp.  857  &  887] 

After  choosing  simulation  as  our  modelling  technique,  we  examined  the 
full  range  of  the  simulation  fidelity  spectrum.  A  brief  discussion  of  models 
found  at  the  extremes  of  this  fidelity  spectrum  will  help  clarify  the  strengths 
of  our  approach. 

At  one  end  of  the  simulation  fidelity  spectrum,  there  exist  models  which 
have  stationary  arrival  processes  of  message-sending  requirements.  These 
processes  are  typically  stationary  Poisson.  This  simple  workload  model  is 
used  because  evaluating  the  resulting  communications  traffic  process  is 
sometimes  analytically  tractable.  This  approach  usually  allows  for  relatively 
inexpensive  development  at  the  expense  of  reality,  usability,  and  user 
acceptance.  Examples  of  this  approach  can  be  found  in  [Ref.  14]. 

At  the  other  extreme  are  models  which  attempt  to  simulate  the  evolution 
of  combat,  thereby  inducing  a  realistic  communications  workload.  Some  of 
the  drawbacks  of  this  approach  are  readily  apparent.  In  order  to  generate  the 
communications  traffic,  the  combat  simulation  must  be  of  high  resolution. 
Thus,  reality  comes  with  significant  model  development  costs,  and 
programming  costs.    Such  models  require  voluminous  input  data,  to  which 
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confidence  in  model  output  is  very  tightly  linked.  Conclusions  drawn  from 
the  results  of  high  resolution  combat  models  are  valid  only  for  the  specific 
scenario  used.  [Ref.  11]  Furthermore,  inclusion  of  details  costs  computational 
effort  with  each  replication  of  the  (obviously  terminating)  scenario,  resulting 
in  extremely  large  computing  requirements  for  meager  accuracy.  These  types 
of  models  display  hard-to-quantify  effectiveness,  as  the  engagement  modeled 
can  take  several  distinct  turns  during  its  evolution.  Most  frustrating,  it 
becomes  very  difficult  to  attribute  changes  in  performance  to  variations  in 
input.  Examples  of  high  resolution  combat  models  for  communications 
performance  analysis  can  also  be  found  in  [Ref.  14]. 

In  this  thesis,  we  describe  a  model  of  MAGTF  communications  traffic 
which  occupies  the  middle  ground  of  the  simulation  fidelity  spectrum 
between  the  extremes  of  simple,  analytically  tractable  Poisson  models  and 
high  resolution  combat  models.  Our  model  uses  a  paradigm  of  Marine  Broad 
Operational  Tasks  (MBOTs),  Broad  Operational  Subtasks  (BOSTs),  and 
Message  Exchange  Occurrences  (MEOs)  to  avoid  the  weak  points  of  the 
simulation  extremes  described  above.  This  paradigm  is  described  in  section 
C.l  of  this  chapter. 

In  summary,  it  is  clear  that  a  simulation  model  is  the  appropriate  tool  for 
analyzing  the  complex  military  communications  process.  It  provides  a  means 
to  experiment  with  proposed  systems  or  architectures  without  actually 
implementing  them.  With  proper  experimental  design  and  sound  statistical 
analysis,  the  results  of  a  simulation  can,  and  often  do,  provide  decision 
makers  with  a  very  effective  decision-making  aid. 
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B.    OBJECT  ORIENTED  PROGRAMMING 

Object-oriented  programming  is  a  design  and  programming  discipline 
that  focuses  on  the  objects  that  make  up  the  system  rather  than  on  the  overall 
function  of  the  system.  While  this  is  at  odds  with  traditional  top-down 
design  techniques,  we  will  see  that  there  are  excellent  reasons  for  adopting 
this  point  of  view.  [Ref.  22] 

This  introductory  section  is  presented  since  object-oriented  programming 
is  fairly  new  to  the  military  and  the  selection  of  a  modelling  language  is  a  key 
part  of  any  computer  modelling  problem.  It  highlights  object-oriented 
programming^  many  strengths  and  the  reasons  for  choosing  MODSIM  II  as 
our  simulation  language.  [See  reference  15  for  details  of  the  MODSIM 
programming  language] 

1.     MODSIM  n 

The  result  of  evolutionary  language  developments,  the  Modular 
Simulation  language,  MODSIM  II,  is  a  general-purpose,  modular,  block 
structured  language  which  provides  support  for  object-oriented  programming 
and  discrete  event  simulation.  It  has  several  advantages  over  non-object- 
oriented  simulation  languages  when  used  in   modelling  complex,  interactive 

sytems  like   military  communications  architectures.  [Ref.  15] 

•  Modularity:  Programs  may  be  (but  are  not  required  to  be)  divided  into 
modules.  Each  module  is  stored  in  a  separate  file.  The  advantages  of 
this  approach  are  that  these  modules  can  be  compiled  separately, 
saving  time  when  only  one  of  them  is  edited.  Modules  can  import 
constructs  and  definitions  from  each  other.  This  modularity  allows 
one  to  easily  model  real-world  sub-systems  as  separate  parts  of  a  large 
model  and  lends  itself  to  multiple  programmers. 
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Block-Structured:  A  block  is  made  up  of  declarations  and  executable 
statements.  It  may  contain  smaller  blocks.  The  important  feature  of 
block-structured  languages  is  that  the  scope  or  visibility  of  variables  is 
restricted  to  the  block  in  which  they  are  declared  and  any  subsidiary 
blocks.  This  feature  helps  to  make  programs  very  reliable  and  easily 
modifiable. 

Object-Oriented  :  An  object  is  an  encapsulation  of  a  data  record  (obejct's 
fields)  which  describes  the  state  of  the  object  and  procedures  called 
methods  which  describe  its  behaviors.  (See  Fig.  7)  Objects  are  more 
concrete  than  most  programming  constructs  in  that  they  exist  as 
individual  entities  throughout  a  program  execution.  They  interact 
through  a  clearly  defined  protocol,  and  the  fields  of  an  object  instance 
can  only  be  changed  by  its  own  methods. 


nitObj  =  OBJECT 

name 

:  STRING; 

unitType 

:  UnitDesignationType; 

loc 

:  UnitLocationRec; 

echelon 

EchelonType; 

division 

INTEGER; 

regiment 

INTEGER; 

battalion 

INTEGER; 

company 

INTEGER; 

platoon 

INTEGER; 

numRadios 

INTEGER; 

radio 

ARRAY  INTEGER  OF  RadioObj; 

netType 

ARRAY  INTEGER  OF  NetDesignationType; 

ASK  METHOD    Objlnit; 

TELL  METHOD   ReceiveBostlnstance  (INIncomingBostPack:  BostlnstanceTxObj; 

IN  IntendedReceiver  :  INTEGER; 

IN  SelectedRadio     :  RadioObj; 

IN  ReceiptStatus      :  ReceiptStarusType); 
TELL  METHOD  ExceptionHandlingRoute 

(IN  IncomingBostPack  :  BostlnstanceTxObj); 
TELL  METHOD  KnowAboutJamming  (IN  Radio  :  RadioObj; 

IN  Index  :  INTEGER); 

Figure  7.  Example  of  MODSIM  Object  with  its  Fields  and  Methods 
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There  are  other  key  object-oriented  constructs  of  MODSIM  II  that  make  it 
such  a  powerful  and  flexible  tool.    These  other  constructs  are  detailed  in  [15] 

for  those  readers  who  are  interested,  but  a  few  are  simply  listed  here: 

•  single  and  multiple  inheritance 

•  dynamic  binding  of  objects 

•  polymorphism 

•  data  abstraction  and  information  hiding 

•  dynamic  memory  management  capability 

As  an  example  of  some  of  the  features  mentioned  above,  we  might  have  two 
unit  types,  rifle  company  and  tank  platoon,  which  are  object  types  derived 
from  the  more  general  unit  object  type.  If  we  ascribe  a  method  called 
receive. order  to  the  unit  object,  then  we  can  invoke  receive. order  for  any 
object  whose  type  inherits  the  unit  object  type.  If,  at  some  point  in  future 
development,  we  wish  to  add  a  Light  Armored  Vehicle  (LAV)  platoon  to  the 
simulation,  we  may  choose  to  inherit  the  properties  of  the  tank  platoon  object 
as  a  starting  point  and  then  modify  the  fields  and  methods  as  necessary.  [Ref. 
11] 

MODSIM  II's  structure  and  syntax  were  based  on  that  of  Modula-2,  so 
programmers  familiar  with  Pascal,  Modula-2,  or  Ada  would  have  little 
difficulty  in  learning  the  language.  Since  it  is  a  strongly  typed  language,  (all 
variables  must  be  declared  by  type),  MODSIM  II  promotes  consistency  and 
reduces  errors  in  user  code.  This  strong  type  checking  ensures  errors  are 
caught  at  compilation  time  rather  than  at  run  time  when  they  would  be 
much  harder  to  find.  [Ref.  15] 

The  speed  and  portability  of  MODSIM  II  are  a  result  of  the  C  code 
which  is  created  by  the  system's  C  compiler.    Compiled  code  means  faster 
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execution  times,  and  allows  it  to  be  highly  portable  across  mainframe,  work- 
stations, and  PC's.  Because  MODSIM  II  supports  automated  separate 
compilation  and  importation  of  code  from  modules  and  libraries,  the 
language  is  ideal  for  large  projects  with  multiple  programmers.  [Ref.  15] 

The  same  modularity  that  facilitates  multiple  programmer  projects 
promotes  easier  code  maintenance  and  improves  reliability  and  code 
reusability.  Objects  and  routines  performing  related  functions  can  be  grouped 
into  modules  which  can  be  put  into  libraries  for  reuse  by  other  programs.  In 
this  manner,  such  common  simulation  requirements  as  statistic  collecting 
and  queue  management  are  already  standardized  and  available  with  the 
language's  built-in  library. 

A  key  area  for  future  MCCAAM  development  work  is  the  integrated 
dynamic  graphics  available  in  MODSIM  which  can  substantially  reduce  the 
time  and  effort  required  to  display  results.  Only  a  few  lines  of  code  are 
needed  to  create  dynamic  icons,  histograms,  clocks  and  meters  that  change  as 
the  program  runs.  With  graphics,  many  results  are  easier  to  explain  and 
understand. 

2.     Object  Oriented  Simulation 

Object-oriented  simulation  and  object-oriented  programming  are 
both  based  on  the  principle  that  the  design  of  a  system  should  be  based  on  the 
objects  that  make  up  the  system.  Three  concepts  characterize  the  difference 
between  object-oriented  programming  and  object-oriented  simulation: 
entities,  events,  and  simulation  time.  [Ref.  22] 

In  an  object-oriented  simulation  some  of  the  objects  are  active.  They 
execute  independently  of,  and  concurrently  with,  other  active  objects.   These 
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active  objects  are  called  entities.  They  are  used  to  model  the  physical  processes 
in  the  system  being  simulated.  In  our  case,  the  unit,  net,  and  radio  objects  are 
all  examples  of  entities  and  a  physical  process  that  they  model  is  transmitting 
and  receiving  messages. 

An  event  represents  a  change  in  the  state  of  one  of  the  objects  in  the 
system  being  simulated.  Entities  schedule  events  for  each  other  to  mark 
when  these  state  changes  are  to  occur.  Events  are  used  either  to  synchronize 
the  actions  of  two  entities  or  to  pass  information  from  one  entity  to  another. 

Entitity  actions  and  event  scheduling  are  both  tied  to  a  logical  clock 
called  simulation  time.  Simulation  time  is  an  arbitrary,  application  defined 
time  scale  that  is  independent  of  real  time.  Each  event  is  tied  to  the  logical 
clock  through  a  scheduled  event  time.  This  event  time  corresponds  to  the 
actual  time  in  the  physical  system  when  the  corresponding  physical  event 
would  occur.  [Ref.  22] 

Given  the  three  concepts  briefly  explained  above,  constructing  object- 
oriented  simulations  involves:  [Ref.  22] 

•      Identifying  the  physical  processes  that  make  up  the  system  being 
defined. 
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Defining  an  entity  class  to  model  each  type  of  physical  process. 

•  Identifying  all  circumstances  that  can  lead  to  changes  in  the  state  of  the 
system  and  characterize  these  as  events. 

•  Determining  when  events  occur  and  tieing  them  to  simulation  time  by 
means  of  their  scheduled  event  time. 

Like  all  process  oriented  (i.e.  not  discrete  event)  simulation  paradigms,  the 

object-oriented  simulation  modeling  framework  has  occasion  to  freeze  a 

process  until  some  time  passes,  some  condition  becomes  true,  or  some 

resource  is  available.   The  utility  offered  by  object-oriented  simulation  is  that 
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this  waiting  is  done  by  a  method  of  an  object.  In  MODSIM  n,  an  object  can 
have  several  concurrent  methods  waiting  for  different  things.  This  allows  for 
autonomy  of  objects,  promoting  reusable  object  code. 

In  summary,  MODSIM  II  is  a  complete,  powerful,  general  purpose 
programming  and  simulation  language.  Its  features  reduce  design  and  coding 
effort  and  improve  reliability.  As  mentioned  previously,  its  modularity 
allows  any  simulation  programmer  to  expand  a  simple  model  into  a  more 
complex  one  with  ease.  This  degree  of  modularity  has  enabled  us  to  quickly 
develop  MCCAAM  using  three  programmer  authors  with  a  graceful  buildup. 
[Ref.ll]  The  degree  of  dynamic  interaction  between  many  varied  units  in 
real-world  military  communications  requires  the  flexibility  and  structure  that 
object-oriented  simulation  affords. 

C    MODEL  DEVELOPMENT 

In  order  to  theorize  about  military  communications  and  the  complex 
military  C3  process  and  to  construct  an  appropriate  model,  it  is  useful  to  have 
a  definition  of  a  C3  system.  For  our  evaluation,  and  in  concert  with  the 
MCES  system  bounding  requirement,  a  C3  system  possesses  the  following 

components  [19]: 

•  physical  entities — refers  to  equipment  (computers  and  peripherals, 
modems,  jammers,  antennas,  batteries,  vehicles),  software,  facilities, 
and  people. 

•  structure — identifies  the  arrangement  and  interrelationships  of 
physical  entities,  procedures,  protocols,  concepts  of  operation,  and 
information  patterns.  (This  frequently  reflects  doctrine  and  may  be 
scenario  dependent.) 

•  process — identifies  the  functions  of  the  system  as  tasks  that  are  being 
carried  out  (receiving,  queueing,  transmitting,  routing,  jamming, 
waiting,  etc.) 
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These  three  components  were  used  as  a  baseline  for  modelling  the 
MAGTF  communications  architectures.  The  external  stresses  that  affect  all  of 
these  basic  components  were  another  foundational  consideration  in 
developing  MCCAAM  and  are  discussed  in  the  following  sections. 

MCCAAM  is  intended  to  be  used  by  the  Marine  Corps  Warfighting  Center 
to  measure  communications  network  and  architectural  performance  under  a 
variety  of  possible  stresses,  as  shown  in  Figure  8. 


Traffic 
Requirements 

Simulation 

Performance 
Measurements 

T 

Stress  Factors 

•  Physical  Environment 
•Threat 

•  Battlefield  Activities 

•  Traffic  Load 

,•  Reliability                               j 

Figure  8.  External  Model  Stresses 


Of  the  5  major  stresses  listed,  MCCAAM  currently  only  models  traffic, 
reliability,  and  a  limited  threat.  It  will  be  useful  for  system  engineering 
functions,  such  as  network  sizing  and  configurations,  as  well  as  operational 
planning.  In  can  also  be  modified  to  support  interoperability  analysis,  threat 
analysis,  test  and  evaluation  planning,  and  any  application  where  a 
communications  network  ability  to  move  traffic  under  battlefield  conditions 
is  a  consideration. 


41 


The  model  design  is  based  on  the  premise  that  the  major  mission  of  a 
MAGTF  communications  network  is  its  capability  to  move  message  traffic 
during  combat.  Actual  performance  is  a  function  of  numerous  battlefield 
factors  that  affect  network  throughput.  The  main  subsystems  of  our 
MCCAAM  model  that  simulate  these  battlefield  factors  are  the 
communications  model,  the  workload  model,  the  jamming  model,  and  the 
reliability  model. 

1.     Communications  Model 

Communications  requirements  within  a  MAGTF  are  outlined  in 
[Ref.  20,  21]  and  depicted  in  MCCAAM  in  terms  of  needlines.  A  needline  is  a 
series  of  related  data  elements  which  describe  a  requirement  to  communicate 
information  between  two  or  more  battlefield  communicators,  hereafter 
described  as  Command  and  Control  Facilities  (C2FACs).  The  makeup  of  these 
"needlines"  is  described  in  the  following  paragraphs  which  detail  the 
workload  modelling. 

The  five  major  Marine  Corps  mission  areas  are  air  operations, 
ground  operations,  intelligence,  fire  support  and  combat  service  support.  The 
MAGTF  Interoperability  Requirements  Concepts  (MIRC)  contains  the  tasks 
performed  by  Marine  Corps  communicators  which  are  similar  to  the  MCES 
standard  functions  of  sense,  assess,  generate,  plan  and  direct.  Each  of  these 
functions  is  performed  by  a  subset  of  the  C2FACS  in  a  MAGTF  in  a  sequential 
fashion  to  accomplish  tasks  in   the  five  mission  areas  above. 

To  capture  the  sequence  of  message  traffic  required  to  accomplish 
certain  operational  tasks,  the  Marine  Corps  Technical  Interface  Design  Plan 
for  Marine  Tactical  Systems  (MTS-TIDP)  defines  three  levels  of  functions  in 
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Volume  II  entitled  Multiple  Agency  Message  Exchange  Sequences  (MAMES) 
At  the  top  level  for  each  of  the  five  mission  areas  are  Marine  Broad 
Operations  Tasks  (MBOTS)  such  as  artillery  call  for  fire  in  the  fire  support 
mission  area.  Each  MBOT  is  then  subdivided,  for  example  standard  fire 
mission,  check  fire  etc.  These  subdivisions  are  called  Broad  Operational 
Subtasks  (BOSTs).  Each  BOST  is  further  subdivided  into  Message  Exchange 
Occurrences  (MEOs).  Each  MEO  explicitly  identifies  the  origin  and 
destination  C2FAC,  the  type  of  message  sent  and  the  net  used  for  each  MEO  in 
accomplishing  the  BOST  as  illustrated  in  Figure  9.  In  addition,  each  MEO 
cross-references  the  interface  task  which  created  it  and  the  next  interface  task 
which  its  receipt  supports.  The  normal  sequence  of  the  MEOs  is  roughly 
indicated  for  each  BOST.  There  are  as  many  as  50  MEOs  for  a  BOST. 

The  following  paragraphs  discuss  how  the  actual  communications 
architecture  was  modeled  in  MCCAAM  primarily  through  the  interaction  of 
Unit,  Radio,  and  Net  Objects.  Figure  10  lists  the  primary  network  objects  in 
MCCAAM  with  most  of  their  accompanying  fields(attributes)  and 
methods(activities). 

a.     Command  and  Control  Facilities  (C2FACs) 

C2FACs  are  the  agencies  that  process  command  and  control 
communications  and  are  modeled  as  Unit  Objects  in  MCCAAM.  Since 
MCCAAM  simulates  actual  procedures  to  generate  and  route  message  traffic, 
it  needs  to  know  what  C2FACs  are  in  the  architecture,  where  they  are  located, 
the  single-channel  nets  they  guard,  and  a  few  additional  pieces  of 
information. 
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The  Unit  Object  is  the  base  type  from  which  we  create  all  of  the 
C2FACs  in  MCCAAM.  Instances  of  C2FACs  range  from  a  platoon 
headquarters  (~  2  radios)  to  a  Brigade  headquarters  (~  20  radios).  The 
communications  equipment  owned  by  a  C2FAC  is  stored  in  a  radio  array 
which  is  a  field  of  each  unit  object.     Each  radio,  in  turn,  is  a  doctrinal 
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Figure  9.  Message  Exchange  Occurrences  Between  C2FACS 
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subscriber  of  a  given  net.  Section  (b)  further  illustrates  the  features  of  the 
radio  objects.  The  differences  between  unit  types  are  found  in  the 
composition  of  the  radio  array,  the  rate  of  BOST  initiation  for  each  type  of 
BOST,  and  the  particular  nets  that  the  unit  is  a  subscriber  of. 


OBJECTS 

FIELDS 

METHODS 

(ENTITIES)                       (ATTRIBUTES) 

(ACTIVITIES) 

Units 

name 

numRadios 

TELL   ReceiveBostlnstance 

location 

netType 

TELL  ExceptionRoute 

echelon 

radio  (array) 

TELL   KnowAboutJamming 

Radios 

unitLoc 

NetType 

TELL  Fail 

netlndex 

Equipment 

ASK  Start(Stop)Receiving 

queue 

Available 

ASK  RequestTransmission 

Jammed 

Transmitting 

ASK  SubmitBost 

Receiving 

MTBF 

ASK  Start(Stop)Transmit 

NumlnQ 

NumMessAtt 

ASK  Become(Un)Jammed 

Nets 

Netlndex 

NetDescriptor 

TELL  EnterNet 

Type 

PropagateMode 

TELL  ChangeFreq 

Netldle 

Equipment 

TELL  ExecuteBusyPeriod 

Frequency 

Netjammed 

ASK  SelectRadio 

Mean  AcknowledgeTime 

ASK  NextTraffic 

RadioList  (linked  list) 

ASK  ConstructWaitingList 

SelectedRadio 

TELL  TransmissionDelay 

Jammers 

Name 

IDNumber 

TELL  Jam 

XCoord 

YCoord 

PROCEDURES: 

Range 

JamBandLow 

Readjammer 

Active 

JBandWidth 

SelectTarget 

Numjammed 

CalcDistance 

Figure  10.      Partial  Attribute  and  Activity  Summary  for  Major  MCCAAM 

Network  Objects 

Each  BOST  is  pursued  via  the  execution  of  MEOs  between  units. 
After  a  unit  receives  an  MEO,  it  checks  the  BOST  to  determine  the  next  MEO 
and  determines  the  appropriate  net  using  the  route  procedure.  Figure  11 
shows  the  interactions  between  the  units,  nets,  and  the  traffic  generator.  [Ref. 
11] 
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As  currently  modeled,  the  main  method  that  the  Unit  object 
owns  is  the  ReceiveBostlnstance  method  which  takes  an  incoming  MEO, 
checks  it  for  accuracy,  and  then  takes  appropriate  action  as  required.  There  are 
circumstances  under  which  the  unit  will  not  be  able  to  reach  some  of  the 
intended  receivers  on  the  net  specified  in  the  BOST.  Thus,  the 
ReceiveBostlnstance  method  makes  a  call  to  a  complex  routing  routine  which 
determines  the  sequence  of  units  who  will  relay  the  BOST  to  the  intended 
receiver. 


UNIT 


UNIT 


UNIT 


Figure  11.  Interaction  Between  TrafficGenerator,  Units,  and  Net 
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b.     Radios 

The  radio  object,  as  mentioned  earlier,  models  the  actual 
characteristics  and  actions  of  the  tactical  radios  in  our  simulation.  Each  radio 
object  has  its  own  fields  and  methods  which  distinguish  its  existence  and 
performance  capabilities  within  the  simulation  model.  Fields  which  identify 
whether  or  not  the  radio  is  down  for  repair,  currently  being  jammed,  or 
currently  transmitting  all  help  to  track  the  individual  performance  of  each 
radio.  Instances  of  the  radio  object  in  MCCAAM  currently  are  the  members  of 
the  VRC-12  family  and  the  SINCGARS  radio  as  well  as  HF  radios  which  are 
often  used  as  an  alternate  route  for  VHF  traffic.  The  main  field  that  the  radio 
object  owns  is  a  prioritized  queue  which  is  used  to  hold  the  MEOs  that  the 
radio  is  waiting  to  transmit.  By  means  of  this  queue,  we  are  able  to  monitor 
the  number  of  waiting  messages  and,  over  time,  gather  a  picture  of  which 
radios  are  used  the  most.  From  within  the  radio  object,  we  also  track  the 
number  of  message  attempts  and  completions  for  each  radio.  As  illustrated 
in  the  unit  description  section,  each  radio  object  is  owned  by  a  unit  and  is 
located  in  that  particular  unit's  radio  array  where  it  can  be  accessed  when 
needed. 

The  main  methods  that  the  radio  base-type  owns  are  the 
RequestTransmission   method,   the   SubmitBost  method,   Becomejammed 
method,  and  the  Fail  method. 
c     Nets 

Voice  radio  nets  are  central  to  our  problem;  as  part  of  their 
respective  object  descriptions,  they  have  access  to  the  different  radio  object 
types  that  we  are  concerned  with  (VRC-12  family  and  SINCGARS).  They  are 
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a  target  of  enemy  jamming,  a  resource  that  is  tied  up  by  a  message 
transmission,  and  a  method  for  re-routing  traffic  when  a  primary  net  is  not 
available  between  any  two  C2FACs.  For  the  results  of  any  MCCAAM  analysis 
to  be  meaningful,  it  is  imperative  that  the  nets  and  the  units  that  are 
subscribers  of  these  nets  reflect  the  actual  nets  and  net  memberships  that  are 
relevant  to  the  question  at  hand.  In  this  case,  the  allocation  of  new 
SHMCGARS  radios. 

The  net  object  is  the  base  type  from  which  all  the  various 
MAGTF  nets  are  created  and  linked  together  to  form  the  communications 
architecture  of  MCCAAM.  Since  radio  net  transmission  time  is  the  only 
limited  resource  in  our  model  (besides  radios)  the  modeling  of  this  resource 
is  key  to  how  the  model  simulates  the  actual  message  handling  of  specified 
nets. 

A  net  may  be  thought  of  as  a  one-talker-at-a-time  party  line 
where  all  the  unit  subscribers  of  the  net  have  the  opportunity  to  hear  every 
message  that  is  transmitted  on  the  net,  but  only  one  subscriber  may  transmit 
at  any  time. 

The  nets  in  our  model  use  a  highest-priority-first  discipline, 
which  may  be  slightly  more  orderly  than  an  actual  tactical  communication 
process.  When  an  opportunity  for  transmission  takes  place,  (i.e.  the  net 
becomes  idle),  the  net  polls  each  of  its  subscribers  using  its  NextTraffic 
method  and  randomly  chooses  one  of  the  units  with  a  highest  priority 
message  waiting  in  queue  This  reflects  reality  in  that  if  several  units  are  all 
trying  to  gain  access  to  a  net  with  equal  priority  traffic,  the  winner  really  is  a 
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random  draw.    This  queueing  discipline  is  easily  varied  by  changing  the 
ExecuteBusyPeriod  method  of  the  net. 

The  other  main  method  that  the  net  objects  own  is  the 
ChangeFreq  method  which  causes  the  current  net  frequency  being  used  by 
fixed  frequency  radios  to  change  in  a  user-defined  periodic  fashion.  This 
method  is  also  called  when  a  fixed  frequency  radio  is  jammed  and  cannot 
work  through  the  jamming.  The  jammer  objects,  as  defined  later,  check 
specific  frequency  bands  and  if  no  net  is  transmitting  in  that  range  band  while 
the  jammer  is  scanning,  the  net  avoids  being  jammed.  See  Figure  11  on  page 
47  for  an  illustration  of  the  jammer/net/unit  interaction. 
2.     Workload  Model 

Stochastic  workload  models  are  normally  used  to  drive 
communication  system  models.  As  mentioned  previously,  these  range  from 
simple  low-resolution  models  that  generate  messages  according  to  stationary 
Poisson  processes  to  extremely  high-resolution  models  that  try  to  simulate 
the  actual  evolution  of  combat  with  all  of  its  inherent  communications.  [Ref. 
29] 

In  order  to  test  the  value  of  a  specific  communications  architecture, 
we  must  stress  the  system  in  a  realistic  fashion.  However,  we  want  our 
conclusions  to  be  independent  of  a  specific  scenario  of  events.  Through 
application  of  the  Modular  Command  and  Control  Evaluation  Structure 
(MCES),  we  have  developed  a  paradigm  for  workload  modeling  that  lies 
between  the  extremes  mentioned  above.  It  exploits  the  information 
promulgated  in  the  Technical  Interface  Design  Plan  (TIDP)  Vol  II  as  described 
in  the  section  on  the  communications   model.      The  structure  of  this 
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document,  which  clearly  defines  each  of  these  items  and  their 
interdependences,  makes  it  possible  to  generate  realistically  interdependent 
message  traffic  without  resorting  to  a  specific  scenario.  This  generation 
process  is  detailed  in  the  following  paragraphs.  [Ref.  29] 

To  generate  traffic  for  the  MAGTF  communication  system,  we 
generate  a  sequence  of  BOSTS  which  are  initiated  by  specific  units  within  the 
force.  Each  unit, ;,  in  the  MAGTF  has  a  particular  rate  of  occurrence,  X[\,  for 
each  of  the  BOSTs,  i,  that  it  could  possibly  originate.  Each  Bost-Unit 
combination  (i,j)  initiates  a  particular  BOST  with  its  own  rate  relative  to  the 
other  BOSTs  and  other  units  within  MCCAAM.  For  our  current  model,  the 
rates  that  are  employed  are  best  estimates  from  a  surveyed  panel  of  officers. 

For  efficiency  and  centralization  of  control,  we  generate  instances  of 
BOSTs  from  a  BOST  master  list  <which  is  easily  manipulated  as  a  data  file)  in 
a  central  process: 

while  (not  TIME'S  UP) 

sample  DELAY  with  mean  =  1  Ar 

wait  DELAY 

choose  a  BOST  and  UNIT 

tell  UNIT  to  INITIATE  BOST 

end  while 

where     X  =  J\.  \&u>     For  a  straightforward  initiation  with  no  intensity 

factor,  r=l.  Given  BOST  i  and  unit  j,  the  BOST-unit  combination  (i,j)  is 
chosen  from  a  multinomial  distribution  with  probability  Aj.-/A.   If  the 

central  delays  are  chosen  to  be  exponential,  then  each  BOST-unit  initiation  is 
a  filtered  Poisson  process.  Otherwise,  each  time  between  BOST-unit  initiation 
is  a  sum  of  a  geometric  number  of  iid  delays. 
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An  example  of  an  operational  task  in  offensive  operations  is  Artillery 
Call  For  Fire,  with  the  constituent  BOST,  Standard  Call  For  Fire.  This  BOST 
might  be  initiated  by  a  Battery  Forward  Observer  (BTRY  FO),  and  it  involves 
the  cooperation  of  the  Artillery  Battalion  Fire  Direction  Center  (BN  FDC),  the 
Battalion  Fire  Support  Coordination  Center  (BN  FSCC),  and  the  Artillery 
Battery  Fire  Direction  Center  (BTRY  FDC)  The  MEOs  which  are  required  to 
complete  the  Standard  Call  for  Fire  BOST  include  the  original  call  for  fire,  the 
clearing  of  the  fire  mission  up  the  chain  of  command,  the  replaying  of  the 
clearance  back  down  the  chain,  the  spotting  and  firing  directions  exchanged 
between  the  BTRY  FO  and  the  BTRY  FDC,  the  end  of  mission  and 
surveillance  messages.  This  BOST  is  a  good  example  of  how  realistic  traffic  is 
produced  in  that  there  are  concurrent  messages  that  go  out  over  monitored 
nets,  conditional  response  type  messages,  and  a  real-world  precedence 
structure  between  the  MEOs.  [Ref.  Ill  The  MEOs  that  need  to  be  sequentially 
accomplished  for  this  BOST  are  illustrated  in  Figure  12. 

Each  specified  message  within  a  BOST  has  associated  with  it  a 
message  format  which  identifies  the  message  originator,  receivers,  net  to  be 
used,  and  a  duration.  The  duration  is  a  modelling  addition  which  allows  us 
to  control  how  long  the  particular  message  will  "occupy"  or  tie-up  a  radio  net. 
A  list  of  the  specific  MEOs  required  for  the  completion  of  each  BOST  is  given 
in  the  TIDP  Vol  II  along  with  a  comprehensive  description  of  the  MEO. 
Therefore,  the  workload  of  our  communications  network  is  the  complete  set 
of  message  durations  of  all  the  MEOs  that  must  occur  to  complete  all  of  the 
BOSTs  initiated  by  all  the  units  in  the  simulation. 
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BOST:  Standard  Fire  Mission 

6Uhits 

5  Nets 

16MEOs 


\  /  REGT  y^  '       Dotted  Lines  represent  "As  Required' 

message  traffic ... 


Figure  12.  Example  BOST:  Standard  FO  Fire  Mission 
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An  interesting  challenge  in  modelling  military  communications 
beyond  the  usual  deterministic  point-to-point,  one-level  message  traffic,  is 
that  many  times  messages  are  intended  as  broadcast  type  messages  which  are 
intended  for  all  children  nodes  on  a  family  tree.  We  model  this  facet  of 
military  communications  with  a  simple  BOST  designation:  PointToPoint  or 
Broadcast.  The  MEOs  within  a  Broadcast  BOST  are  cloned  on-the-fly  to  meet 
the  intended  receiver  requirements.  In  this  manner,  the  conditional  nature 
of  our  workload  paradigm  is  greatly  magnified  and  exercised.  This  facet  of 
MCCAAM  alone  distinguishes  it  from  normal  communication  simulation 
models. 

To  achieve  realism,  we  specify  several  aspects  of  a  general  situation 
for  our  MCCAAM  environment  that  help  determine  the  extent  of  the 
MBOTS  that  will  be  involved.  For  example,  the  assumption  that  our  MAGTF 
is  already  ashore  and  engaged  eliminates  the  use  of  the  MBOT  "Warfighting 
Ship  to  Shore  Operations."  Based  on  the  assumed  information  about  the 
units  involved  in  the  MAGTF  simulation  (i.e.  location  and  mission),  we  can 
more  realistically  specify  the  relative  frequency  with  which  each  unit  initiates 
each  type  of  BOST.  For  example,  an  infantry  battalion  in  reserve  will  not  be 
initiating  as  many  calls  for  fire  as  will  a  battalion  engaged  in  a  forward  area  of 
operations.  The  object-oriented  nature  of  our  model  will  allow  very  easy  and 
graceful  upgrades  to  include  any  level  of  detail  desired  in  the  actual  simulated 
environment.  As  mentioned  before  though,  our  emphasis  in  modeling  was 
only  to  include  those  elements  of  the  tactical  environment  that  would 
directly  affect  the  communications  process. 
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The  use  of  the  MBOT/BOST/MEO  framework  briefly  discussed  above 
allows  us  to  model  the  tasks  that  any  given  MAGTF  communications 
network  would  be  required  to  undertake  without  mimicking  detailed 
attrition  engagements.  We  initiate  BOSTs  according  to  a  static,  stationary 
process  and  let  the  workload  paradigm  provide  the  realism;  we  get  the 
communications  realism  of  a  combat  model  without  the  large  development 
costs  or  narrow  focus.  This  structure  also  allows  us  to  compare  alternative 
architectures  under  varying  workloads  without  sacrificing  realism;  we  simply 
adjust  the  rate  (intensity)  of  the  BOST  initiation  process.  [Ref.  29] 
3.     Jamming 

Significant  radio  jamming  threats  exist  in  several  of  the  world's  areas 
of  interest.  MCCAAM  includes  a  model  of  these  threats  to  provide  a  realistic 
environment  for  communications  system  evaluation.  This  is  especially 
important  because  the  SBMCGARS  radios,  with  their  frequency  hopping 
capability,  are  much  more  resistant  to  jamming  than  the  current  radios  as 
Figure  13  illustrates.  Thus,  the  relative  value  of  a  specific  architecture  of  old 
and  new  radios  is  largely  measured  in  the  ability  to  perform  critical 
communications  in  the  presence  of  jamming. 

a.     EW  Definition  and  Scope 

Electronic  Warfare  is  any  military  action  involving  the  use  of 
electromagnetic  energy  to  exploit,  reduce,  or  deny  the  enemy  use  of  the 
electromagnetic  spectrum.  Normally,  the  electromagnetic  warfare  arena  is 
broken  down  into  three  separate  functional  areas.  The  first,  electronic 
support  measures  (ESM)  pertains  to  those  measures  related  to  electronic 
search,  interception,  and  location.     The  second  area  is  that  of  electronic 
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counter  measures  (ECM),  which  is  the  active  portion  of  the  electronic  warfare 
arena.  ECM  involves  jamming  employment  and  the  use  of  other  equipment 
to  disrupt  the  use  of  communications  or  noncommunications  devices  in  the 
electromagnetic  spectrum.  Imitative  deception  falls  into  this  category.  The 
third  functional  area  is  that  of  electronic  counter  counter  measures  (ECCM). 
ECCM  deals  with  those  measures  that  a  force  takes  to  ensure  friendly  use  of 
the  electromagnetic  spectrum  and  to  reduce  enemy  ESM  and  ECM 
effectiveness.  [Ref.  9:p.  60] 
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Figure  13.  Effects  of  Jamming  on  Fixed  Frequency  and  Frequency  Hopping 

Radios  [Ref.  10] 
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b.     Enemy  EW  Techniques 

To  provide  an  example  of  how  enemy  ESM  and  ECM  resources 

are  expected  to  be  utilized,  Figure  14  is  provided.   Note  that  within  25  seconds 

after  transmitting,  a  station  is  expected  to  be  intercepted  and  its  approximate 

location  identified.    Within  three  minutes,  some  type  of  ECM  action  such  as 

incoming  artillery  fire  or  jamming  can  be  expected.  [Ref.  10]  These  times,  of 

course,  are  based  on  optimal  conditions  favoring  enemy  electronic  warfare 

efforts.      Terrain   obstacles,   transmission   time,   power   output,   antenna 

directivity,  and  movement     all  play  important  roles  in  the  success  of 

electronic  warfare.  All  are  variables  that  can  be  modeled  to  reflect  reality  more 

closely,  but  the  important  factor  that  we  considered  was  this:  does  it  help  to 

delineate  between  competing  radio  architectures? 

There  are  many  types  of  jamming  signals  that  may  be  used 

against  a  targeted  receiver.   Some  will  be  quite  difficult  to  detect  and  in  some 

cases  impossible.    For  this  reason,  an  operator  must  always  be  alert  to  the 

probability  of  jamming  and  react  according  to  local  unit  standard  operating 

procedures  (SOP).    Other  jamming  signals  are  clearly  noticed  as  such.    The 

more  commonly  used  types  are  [Ref.  27]: 
Random  Noise 
Recorded  Sounds 
Random  Pulse 
Stepped  Tones 
Pulse 
Tone 
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COMMUNICATION 
.     INITIATED  BY  US 
TRANSMITTER 

IICONDt 


ENEMT  COMINT  OPERATOR  SEARCHINO  VHF 
8ANO  IDENTITIES  A  US  TRANSMITTER  AND 
FLASHES  AURT  TO  RDF  STATIONS  NET  CONTROL 


JAMMINO   MISSION  nil   MISSION  COMSAI   MISSION       INIIUIOINCI  MISSION 

aamagjB 


Figure  14.  Example  Threat  Jamming  Procedures 
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c.  Enemy  EW  Impact  on  Communications 

Radio  operators  must  be  able  to  determine  whether  or  not  their 
radios  are  being  jammed.  As  was  mentioned  in  the  previous  paragraph,  this 
is  not  always  an  easy  task.  Threat  jammers  may  employ  obvious  or  subtle 
jamming  techniques.  These  techniques  may  consist  of  powerful 
unmodulated  or  noise-modulated  carrier  signals  transmitted  to  the  operator's 
receiver.   Unmodulated  jamming  signals  are  characterized  by  a  lack  of  noise. 

If  radio  operators  suspect  that  their  radios  are  the  targets  of  threat 
jamming,  there  are  many  procedures  which  help  them  to  make  this 
determination  and  re-establish  communications.  If  tests  indicate  the 
probability  of  jamming  being  present,  the  operator  would  follow  local  SOP  to 
reestablish  communications  and  also  to  initiate  a  Meaconing,  Intrusion, 
Jamming  and  Interference  (MIJI)  Report  informing  highter  headquarters  of 
the  jamming.  [Ref.  27] 

As  difficult  as  it  can  be  to  detect  jamming,  even  more  so,  the 
modeling  of  the  many  possible  forms  of  jamming  is  very  complex  and 
difficult  to  implement.  The  next  section  details  how  we  implement  the 
jammer/receiver  interaction  and  the  subsequent  communications  time  delay 
that  results. 

d.  Modeling  Enemy  EW 

As  mentioned  previously,  the  only  electronic  warfare  modelled 
in  this  thesis  focuses  primarily  on  the  enemy's  ability  to  jam  friendly 
transmissions.  The  modeling  of  interception  and  direction  finding  will  add 
to  the  resolution  of  the  model,  but  we  assumed  it  would  not  necessarily  help 
to  distinguish  between  alternative  system  configurations. 
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To  include  the  enemy  jamming  threat  and  resultant  stress  in 
our  network  model  we  developed  the  jammer  object.  We  describe  its  fields 
and  methods  in  Appendix  A.  The  JammerMasterList  is  an  array  in 
MCCAAM  that  contains  references  to  all  the  specific  jammers  included  in  any 
given  simulation  run  and  is  used  to  access  specific  jammers  by  name  or 
location  throughout  the  simulation  run.  The  user  controls  the  modeling  of 
jammer  interaction  with  a  simple  boolean  variable  in  the  run  data  file. 

If  jamming  is  to  be  incorporated  in  a  given  run,  the  jammers 
residing  in  the  jammer  data  file  are  created  and  can  be  activated  at  any 
particular  time.  After  creation  of  each  jammer  object,  the  SelectTarget 
procedure  is  called  to  find  all  the  units  currently  within  the  jammer's  range 
and  operational  sector.  If  a  unit  is  within  range  and  sector  and  is  transmitting 
over  any  fixed-frequency  radios,  the  JammerObj  then  checks  to  see  if  those 
radios  are  operating  within  the  frequency  range  he  is  currently  monitoring.  If 
so,  the  jammer  then  proceeds  to  jam  those  radios  for  a  user  determined 
length  of  time.  The  effect  of  this  jamming  is  to  make  the  radios  unavailable 
for  receiving  any  more  MEOs  from  the  particular  net  that  it  is  a  subscriber  of. 
Note  that  as  in  the  real  EW  environment,  the  jammer  only  affects  the 
receiving  radios — not  the  transmitters.  This  will  have  the  effect  of  slowing 
down  the  BOST  completion  times  and  create  delays  throughout  the  network. 
To  what  extent  this  jamming  will  impact  the  architecture's  overall 
accumulated  penalty  is  one  of  the  chief  design  questions  of  the  MCCAAM 
model. 
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4.     Reliability 

There  is  a  significant  improvement  in  mean  time  between  failures 
(MTBF)  with  the  adoption  of  the  new  SINCGARS  radios.  This  improvement 
is  discussed  in  Chapter  IV.  MCCAAM  reflects  this  improvement  in  terms  of 
the  overall  system's  operation  through  reduced  radio  failures  and  down  time. 
This  section  provides  some  brief  background  into  how  we  approached  the 
modelling  of  this  critical  area. 

Generally,  it  is  more  informative  to  study  times  between  failures, 
rather  than  numbers  of  failures,  for  a  continuous  time  communication 
system.  The  most  commonly  used  model  for  describing  the  times  between 
failures  for  such  a  continuous  time  system  is  the  exponential  model.  In  order 
to  model  a  radio  system's  failure  as  an  exponential  distribution,  the  following 

conditions  are  required  and  were  assumed  to  be  true  in  MCCAAM: 

•  the  radio  system  is  as  good  as  new  after  each  repair, 

•  the  probability  of  failure  in  any  given  interval  of  time  is  the  same  no 
matter  how  old  a  system  is  and  no  matter  how  many  failures  it  has 
experienced. 

The  second  condition  above  is  an  intuitive  description  of  the 

memory-less  property.    For  electronic  oriented  hardware  like  the  radios  in 

our  model,  this  memory-less  property  is  not  an  unrealistic  assumption  since 

modern  day  electronics,  once  past  burn-in,  tend  to  exhibit  a  no  wear-out 

lifetime.     A  future  embellishment  in  this  area  would  be  to  model  the 

reliability  failures  with  some  form  of  Weibull  distribution  where  the  radios 

would  exhibit  some  form  of  wear-out  over  time.    The  possible  benefits  from 

such  a  model  embellishment  are  the  topic  of  another  current  thesis.  [Ref.  23] 
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Given  the  reliability  background  above,  we  proceed  now  to  briefly 
discuss  the  implementation  of  reliability  modelling  in  MCCAAM. 

Initial  reliability  failures  are  generated /scheduled  to  occur  for  each 
radio  in  the  simulation  at  the  beginning  of  each  simulation  run  based  on  a 
random  draw  from  the  exponential  distribution.  The  mean  time  between 
failures  (MTBF)  for  the  given  type  of  radio  is  used  as  the  mean  parameter  for 
the  exponential  draw.  When  a  scheduled  reliability  failure  comes  up  on  the 
simulation  "calendar/'  the  boolean  AVAILABLE  field  of  the  radio  is  changed 
to  FALSE.  This  causes  an  interruption  in  traffic  transmission  if  the  radio  is 
in  use  at  the  time.  If  the  radio  was  not  in  use  at  the  time  of  the  failure,  its 
unavailability  is  modeled  by  causing  that  radio  object  to  wait  for  that  radio 
type's  mean  time  to  repair.  Once  a  radio's  modeled  repair  time  is  completed, 
it  becomes  available  again  for  processing  further  traffic.  It  is  at  this  point  that 
modelling  redundancy,  in  the  form  of  radio  spares,  would  impact 
communications  performance. 

Although  we  collect  the  number  of  radio  failures  for  each  type  of 
radio  in  MCCAAM,  a  measure  of  effectiveness  of  our  communications 
system  reliability  is  not  implemented  in  this  analysis.  Analysis  of  system 
reliability,  availability,  and  maintainability  is  a  recommendation  for  future 
study  discussed  in  Chapter  VII. 
5.     Random  Variables 

The  necessary  stochastic  elements  of  MCCAAM  are  obtained  through 

random  number  draws  from  the  following  distributions: 

•  Relative  frequency  of  BOSTs  is  obtained  by  drawing  the  mean  inter- 
generation  time  from  a  gamma  distribution  with  mean  and  shape 
parameter  determined  by  the  user. 
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•  NextTraffic.  When  a  net  is  polling  all  of  its  subscribers  to  see  who  will 
have  the  next  opportunity  to  send  traffic,  if  there  is  a  tie  for  highest 
priority  traffic,  then  there  is  a  random  draw  to  determine  which  unit 
gets  the  privilege.  The  random  draw  is  from  a  uniform  distribution  [0, 
number  of  subscribers]. 

•  Message  durations  are  currently  deterministic,  but  the  code  is  in  place 
to  allow  messages  to  vary  according  to  a  normal  distribution  with 
mean  and  variance  defined  by  the  user. 

•  Radio  failure  times  are  drawn  from  an  exponential  distribution  with 
mean  time  between  failures  as  key  parameter. 

•  Jamming  sector  and  frequency  band  are  random  draws  from  a  uniform 
distribution. 

•  Frequencies  of  fixed-frequency  radios  are  drawn  from  uniform 
distribution  [33.0, 88.0]. 

D.    MODULE  DESCRIPTIONS  AND  RESOLUTION 

As  described  in  section  B  of  this  chapter,  MODSIM  is  a  modular  language 
which  allows  separate  compilation  of  blocks  of  code.  Once  a  module  has 
been  compiled,  its  routines,  types,  variables,  and  data  structures  may  be 
imported  and  used  by  other  modules.  [Ref.  15] 

There  are  two  major  types  of  modules  in  MODSIM: 

•  Main  Modules 

•  Library  Modules 

Since  MCCAAM  takes  full  advantage  of  MODSIM's  modularity  and  is  not 
housed  in  one  large  main  module,  the  bulk  of  the  simulation  code  is  found 
in  the  library  modules.  There  are  two  parts  to  a  Library  Module:  the 
DEFINITION  MODULE  and  the  IMPLEMENTATION  MODULE.  The 
definition  module  contains  descriptions  of  those  aspects  of  the  library  module 
which  can  be  imported  by  other  modules  and  it  acts  as  a  type  of  summary  for 
a  particular  object's  characteristics  and  abilities.   The  implementation  module 
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contains  the  code  which  implements  the  functionality  of  the  module;  this  is 
where  the  main  logic  and  conditioning  procedures  and  methods  are  detailed. 

Although  a  very  significant  amount  of  this  thesis  work  was  in  the  actual 
development,  writing,  compiling  and  debugging  of  the  MODSIM  code  that 
makes  up  MCCAAM,  the  extensive  number  of  modules  that  are  used  (more 
than  70)  will  not  be  detailed  here  in  the  body  of  the  thesis.  Appendix  G  is  a 
listing  of  all  the  modules  and  gives  an  indication  of  the  nature  of  the 
modules  that  were  created.  Module  summaries  listing  the  fields  and 
methods  of  the  key  objects  are  found  in  Appendix  D.  For  those  that  are 
interested  in  the  actual  implementation  code,  the  MCCAAM  users  manual 
[Ref.  32]  contains  a  synopsis  of  the  tasks  each  of  the  modules  performs  within 
a  simulation  run. 

The  level  of  resolution,  (the  level  of  detail  that  was  modeled  in  the 
communication  process)  found  in  MCCAAM  was  dependent  on  whether  or 
not  the  added  detail  would  affect  the  system  's  performance  when  different 
radio  technologies  were  used.    Resolution  is  summarized  for  MCCAAM's 

major  objects  below: 

•  Units  :  Simply  a  base  object  for  the  C2FACs,  only  the  location,  number 
of  radios,  types  or  radios,  nets  subscribed  to  and  echelon  of  the  unit  are 
modeled.   No  movement  or  firepower  attributes  modeled. 

•  Nets  :  Besides  name,  propagation  mode,  frequency  and  subscriber  radio 
*  types,  the  Net  Obj    keeps  track  of  whether  it  is  idle  or  not  and  if  it  is 

being  jammed.  It  maintains  a  linked  list  of  all  subscriber  radios. 

•  Radios  :  The  radios  are  modeled  at  the  operational  level.  No  specific 
internal  functions  are  modeled.  The  Radio  Object  keeps  track  of 
whether  it  is  transmitting,  receiving,  being  jammed,  or  idle.  It  tracks 
the  number  of  messages  waiting  in  its  transmission  queue  and  how 
many  transmissio  attempts  it  has  made.  It  knows  its  type,  frequency, 
location,  parent  unit  and  whether  or  not  it  is  "down"  for  a  reliability 
failure.   Antenna  types,  heights,  and  radio  power  are  not  brought  into 


64 


the  model  yet.    Effects  of  terrain  and  weather  are  not  considered  as 
impacting  transmissions. 

•  Jammers:  Leaving  much  room  for  embellishment,  the  jammers  are 
also  modeled  at  the  operational  level,.  The  jammers  have  an 
operating  band  width,  a  max  range,  a  location,  and  an  alternating  sector 
of  search.  They  keep  track  of  the  number  of  attempts  and  successed 
when  jamming  units  within  range,  sector,  and  band  width.  The 
direction  finding  process  is  not  modeled  in  detail.  Different  types  of 
jamming  are  not  modeled.  Jammer  movement  is  not  modeled. 
Jammer  knowledge  of  high  priority  target  nets  is  not  modeled. 

E     MCCAAM  PROGRAM  FLOW 
1.     Model  Runtime  Environment 

MCCAAM  is  embedded  in  a  run-time  environment  (Figure  15) 

which  includes: 

•  database  creation,  manipulation,  and  maintenance; 

•  model  control; 

•  model  execution; 

•  output  analysis. 

The  MCCAAM  database  consists  of  specifications  of  the  units,  nets, 
and  BOSTs  which  are  to  be  examined  for  potential  use.  The  user  has  the 
opportunity  to  adopt  a  baseline  MEU,  MEB,  or  MEF  configuration,  and  then 
to  revise  these  configurations  to  suit  the  precise  force  or  architecture  under 
study.  The  user  can  save  the  constructed  system  under  a  user-specified  name 
for  future  use.  All  of  the  database  functions  are  menu  driven  and  self 
explanatory. 

Model  control  is  the  stage  where  the  user  may  exert  control  on  the 
behavior  of  some  of  the  objects.  There  are  several  ON /OFF  choices  to  be 
made  such  as  whether  to  model  radio  failures,  whether  jammers  are  present 
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Figure  15.  MCCAAM  Simulation  Flow 

for  the  run,  the  method  of  jammer  target  selection,  and  several  other 
features.  The  user  also  specifies  the  duration  of  the  model  run,  and  the  initial 
value  of  the  traffic  workload  rate. 

Model  execution  is  the  phase  where  the  model  constructs  sample 
paths  of  communications  network  specified.  MCCAAM  differs  from  most 
computer  simulations  in  that  all  of  the  objects  in  the  simulation  are 
dynamically  constructed  using  the  data  found  in  the  database.  That  is,  the 
program  itself  has  no  units,  nets,  radios,  or  C2FACs.  The  simulation  contains 
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only  specifications  of  the  behavior  of  these  objects.  Thus,  the  program 
instantiates  the  MAGTF  communications  network,  the  BOSTs,  and  the  traffic 
generator  with  whatever  size,  scope,  and  relationships  are  described  in  the 
database.  [Ref.  11] 

The  output  analysis  stage  of  the  run-time  environment  is  described 
in  Chapter  VI. 

2.     MCCAAM:  An  Inside  View 

To  further  detail  the  events  that  comprise  an  instance  of  MCCAAM, 
the  following  list  shows  the  general  order  that  is  followed  upon  execution: 
cl     SimBuild 

Events  occur ing  prior  to  simulation  start: 

•  Global  variables  initialized  and  read  in  from  data  files. 

•  Traffic  Generator  and  Penalty  Accumulator  created  and  initialized. 

•  All  nets  created  based  on  user  chosen  data  file. 

•  For  each  unit  that  is  created: 

i)       Radios  are  created  and  initialized 

ii)     Units  are  made  subscribers  on  appropriate  nets. 

iii)    Appropriate  BOSTs  are  connected  to  units  for  future  traffic. 

•  For  each  BOST,  MEO  durations  are  read  in  from  data  file  and  specific 
messages  are  initiated. 

b.     SimRun 

The  following  events  occur  during  execution: 

Traffic  Generator  initiates  BOST  occurrences  at  BOST  specified  rates 

Units  are  selected  to  initiate  respective  BOSTs 

BOST  transmission  packet  and  associated  records  created  from  BOST 
master  file. 

Appropriate  MEOs  for  BOST  obtained  for  transmission  by  Unit. 

Timers  for  BOSTs  created  and  all  fields  assigned. 

All  Units  that  will  initiate  BOSTs  are  told  to  receive  BOST  "instances" 
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•  For  each  BOST,  the  following  cycle  occurs: 

+         Completion  status  checked  and  updated. 

+         Route  procedure  called  to  begin  transmission  of  MEOs 

*  Transmission  Radios  on  proper  net  obtained 
(wait  if  not  available). 

*  Net  entered. 

*  Destination  location  obtained 

*  Destination  radio  checked  to  see  if  active  and  on  the  net. 

*  Alternate  route  determined  if  appropriate. 

+         MEO  transmitted — if  more  than  one  receiver,  MEO  is  cloned. 
+         Appropriate  message  duration  time  ties  up  net,  then  net  is 
released  and  MEO  terminated. 

•  Repeat  cycle  from  the  top. 

While  the  cycle  of  MEO  transmission,  reception,  routing,  and  waiting 
is  going  on,  each  BOST's  Timer  is  running.  A  method  periodically  checks 
each  BOST  to  see  if  all  of  its  MEOs  are  completed.  If  they  are,  and  all  were 
completed  before  the  allowed  time  for  that  BOST,  the  Timer  is  interrupted 
and  disposed  of.  Otherwise,  penalty  information  is  obtained  from  the  Timer 
object  and  assessed  until  the  BOST  is  either  completed  or  perishes,  or  the 
simulation  ends. 

F.     DATA  INPUT,  REQUIREMENTS,  AND  ASSUMPTIONS 

As  with  any  simulation  model  that  desires  to  reflect  reality  in  some 
respect,  one  of  the  most  difficult  areas  to  overcome  in  developing  MCCAAM 
was  the  collection  and  construction  of  data  needed  to  drive  the  simulation 
sub-systems.  When  we  learned  that  the  Warfighting  Center  could  not 
provide  the  workload  data  base,  we  selected  the  BOST,  MEO  workload 
structure  as  described  previously.  Using  the  Marine  Corps  Tactical 
Communications  Architecture  (MCTCA)  and  the  Technical  Interface  Design 
Plan  (TIDP),  we  discovered  that  the  selection  of  appropriate  nets,  BOSTs,  and 
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message  lengths   to  include  in  the  analysis  was  not  a  straightforward  process. 

[Ref.  28]  Typical  difficulties  we  encountered  were: 

•  The  documents  provided  (MCTCA,  TIDP,  and  MIRC)  were  written  for 
a  MEF  sized  MAGTF.  Therefore  considerable  expert  screening, 
alteration,  and  augmentation  was  required  to  build  the  information  for 
aMEB. 

•  Each  MEO  requires  transmission  between  two  command  and  control 
facilities  (C2FACs),  but  messsage  numbers  and  durations  were  often 
missing. 

•  Expert  judgment  was  required  to  select  a  subset  of  the  BOSTs  to  include 
in  the  analysis.  If  no  net  for  any  MEO  in  a  BOST  was  to  be  involved  in 
the  SINCGARS  architecture,  the  BOST  was  not  included. 

•  Some  non-VHF/FM  nets  should  be  included  as  alternative  routes 
when  the  primary  net  is  being  jammed,  but  the  proper  subset  requires 
expert  judgment  based  on  the  BOSTs  and  C2FACs  already  selected. 

The    following    bullets    highlight    the    major    areas    of    data    input 

requirements  and  our  corresponding  assumptions[Ref.  29]: 

•  Requirements:  BOST  applicability  to  model  level,  relative  frequencies 
of  BOSTs  for  particular  types  of  units,  allotted  time  for  each  BOST,  one- 
time penalty,  penalty  rates,  pierishability  point. 

Assumptions:  Since  no  sources  could  be  found  for  determining 
doctrinal  relative  frequencies  for  these  BOSTs,  (Desert  Storm  data  is  a 
future,  possible  lead)  we  have  made  best  guess  estimates.  These 
relative  frequencies  of  occurrence  can  be  easily  changed  by  any  analyst, 
and  since  our  focus  is  architecture  selection,  not  precise  modeling  of 
the  real  traffic,  the  frequency  information  need  only  be  reliable  enough 
to  judge  the  relative  worth  of  different  architectures.  Easily  modified, 
these  input  data  values  are  the  same  across  simulation  runs  comparing 
different  architectures. 

•  Requirement:  Intensity  of  overall  traffic  flow 

Assumption:  Given  that  we  are  interested  in  a  given  network's 
operational  capacity  at  times  of  intense  stress,  this  parameter  is  easily 
modified  to  provide  increasing  message  traffic. 

•  Requirement:  Sufficient,  pertinent  message  traffic  to  stress  network 

Assumption  :  Of  the  184  BOSTs  listed  in  the  TIDP  Vol.  II,  only  a 
limited  subset  of  BOSTs  is  included,  but  those  that  are  have  been 
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screened  to  ensure  applicability  to  the  nets  included  in  the  given 
network.  Since  all  possible  messages  are  not  being  stimulated  and  we 
need  to  sufficiently  stress  the  network,  we  increase  the  rate  that  the 
limited  BOSTs  are  generated  until  we  can  analyze  periods  of  heavy 
traffic. 

•  Requirement:  Scenario  Data 

Assumption:  MEB  sized  MAGTF  is  engaged  in  desert  combat.  Unit 
locations  and  collocations  per  general  doctrine.  Radio  allocations 
made  within  doctrinal  table  of  organization  (TO)  to  support  respective 
analysis  objectives. 

•  Requirement:  Appropriate  Jammer  data 

Assumption:  Since  not  modelling  the  direction  finding  equipment  or 
process,  we  assume  that  the  target  selection  has  already  taken  place. 
This  is  modelled  in  zero-time.  Once  the  threat  jammer  has  targets  in 
range,  in  sector,  and  in  band-width,  we  assume  each  jammer  is  only 
effective  in  his  specified  range  and  jamming  band  width.  We  assume 
all  jammers  use  an  overt  jamming  method  such  as  barrage  jamming 
with  noise. 

Our  model  is  intentionally  designed  to  facilitate  easy  specification, 
modification,  or  re-specification  of  the  input  data.  This  is  accomplished 
through  an  extensive,  interactive,  menu  driven  program  called  DB  (Database 
Build)  which  allows  a  user  to  choose  any  MAGTF  level  (MEU,MEB,  or  MEF) 
and  any  of  the  main  building  block  areas  of  data  specification  (Unit,  Net,  Bost, 
MEO,  Jammer)  to  input,  alter,  or  cross  reference.  Through  the  use  of  this  very 
helpful  set  of  data  manipulation  routines,  the  Warfighting  Center  (WFC)  or 
any  other  user  can  verify  which  units  are  attached  to  which  nets,  and  which 
units  generate  specific  BOSTs  as  well  as  a  host  of  other  items  of  interest. 

The  following  list  itemizes  most  of  the  input  variables  that  a  MCCAAM 

user  might  be  interested  in  changing: 
Units:    name,  location,  number  of  radios 
Nets:    name,  number  of  subscribers, 
Radios:    MTBF,  type,  net  index 
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Jammers:  name,  location,  range,  effective  band  width 

Messages:    descriptor,  duration 

BOSTS:  descriptor,  precedence,  alloted  time,  one-time  penalty,  penalty  rate, 
perishability,  number  of  MEOs,  initiators 

Simulation  Run  Data:  scenario  stop  time,  number  of  replications,  model 
jammers,  model  failures,  max  message  re-trials,  MEO  duration 
variabilily,  mean  acknowledgement  time,  acknowledgement 
variability,  time  between  frequency  changes,  net  entry  times  by  radio 
type 

Traffic  Generator:  pace,  interstimulation  time,  intensity  rate 

G.    MODEL  SPECIFICATION  SUMMARY 

The  following  bullets  provide  a  brief  summary  of  interesting  model 

specifics: 

IMPLEMENTATION    LANGUAGE:        MODSIM     II  vs.  1.6  with 
SIMGRAPHICS  vs.  1.3 

SIMULATION  CLASSIFICATION:   Process-oriented,  discrete  event 

Effective  for  Terminating  and  Steady-State  Analysis 

More  than  70  modules 

More  than  30,000  lines  of  code 

Portable  across  computing  architectures: 

*  Initially  developed  on  PC  (DOS) 

*  Moved  to  SUN  workstation  (UNIX) 
Extensive,  menu-driven  data  base  manipulation  program 
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IV.  MEASURES  OF  SYSTEM  PERFORMANCE 

A.    GENERAL 

Judicious  use  of  operational  systems,  such  as  a  MAGTF  communications 
architecture,  requires  an  understanding  of  how  to  measure  the  performance 
and  relative  contributions  of  sub-system  components  to  mission  success.  This 
understanding  is  greatly  enhanced  by  the  proper  selection  and  study  of 
appropriate  measures  of  effectiveness  (MOEs).  In  dealing  with  the  issues  of 
system  performance,  the  analytic  community  has  developed  the  following  set 

of  inter-related  terms  to  use  when  evaluating  the  behavior  of  system:  [Ref.  5] 

•  Dimensional  Parameters 

•  Measure  (Variables)  of  Performance  (MOPs) 

•  Measures  of  Effectiveness  (MOEs) 

•  Measures  of  Force  Effectiveness  (MOFEs) 

Agreement  has  not  been  reached  about  how  the  general  terms  mentioned 
above  can  be  explicitly  defined  to  be  comprehensive  and  distinguishable  from 
one  another.    Therefore,  the  following  definitions  are  presented  for  use  in 

this  thesis  [Ref.  5]: 

•  Dimensional  Parameters — Properties  or  characteristics  inherent  in  the 
radios  whose  values  determine  communication  behavior  and  the 
structure  under  question,  even  when  at  rest  (size,  weight,  number  of 
frequencies,  power  output). 

•  Measures  of  Performance — Closely  related  to  inherent  parameters 
(physical  and  structural)  but  measure  attributes  of  independent  radio 
behavior  (gain,  throughput,  signal-to-noise  ratio). 

•  Measures  of  Effectiveness — Measure  of  how  the  system  performs  its 
functions  within  an  operational  environment  (speed  of  service, 
percentage  of  transmissions  jammed,  number  of  messages  requiring  re- 
routing). 
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•  Measures  of  Force  Effectiveness — Measure  of  how  a  given 
communication  system  and  the  force  (sensors,  weapons,  vehicles)  of 
which  it  is  a  part  performs  missions  (i.e.  how  does  it  contribute  to  battle 
outcome).  This  thesis,  as  mentioned  before,  does  not  attempt  to 
determine  directly  any  such  force  effectiveness  measures. 

MOEs  are  measured  relative  to  some  standard,  which  is  often  implicitly 
how  a  perfect  system  would  perform.  We  use  a  variation  of  this  standard  in 
that  a  baseline  system's  performance  is  used  to  compare  system  performance 
across  the  areas  of  interest.  Since  the  VRC-12  family  of  radios  have  been 
around  for  a  long  time  and  there  is  much  corporate  knowledge,  both 
technical  and  subjective,  about  its  strengths  and  weaknesses,  we  use  it  as  the 
standard  when  assessing  the  qualitative  MOEs.  [Ref.  5] 

It  is  an  accepted  fact  that  MOEs,  as  well  as  MOFEs,  are  related  to  the 
operational  context  of  the  model  and  to  assumed  enemy  actions.  As  such, 
they  are  always  inherently  scenario  dependent  to  some  extent.  To  help  avoid 
this  problem  in  MCCAAM,  we  allow  the  user  complete  freedom  to  change 
those  factors  that  will  impact  communications  performance.  For  example,  we 
focus  on  jamming  as  the  key  aspect  of  enemy  electronic  counter  measures 
(ECM)  abilities.  The  amount  and  extent  of  enemy  jamming  can  be  quickly 
changed  to  provide  easy  sensitivity  analysis  as  this  factor  is  changed. 

B.    CHARACTERISTICS  OF  MEASURES 

Performance  and  effectiveness  measures  can  be  characterized  by  their 
physical  and  analytic  attributes.  [Ref.  5:p  6-12]  Analytic  attributes  are  desirable 
characteristics  that  can  serve  as  a  useful  guide  to  analysts  in  selecting 
appropriate  measures.  The  following  four  characteristics  are  considered  by 
many  to  be  particularly  critical  to  a  successful  analysis  and  were  used  in 
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deciding  which  measures  to  apply  to  MCCAAM  analysis.    Additional  criteria 

for  evaluation  measures  are  listed  in  Table  2. 

•  Mission  Oriented — The  measure  selected  should  be  related  to  a  clearly 
defined  statement  of  the  mission,  or  objective,  of  the  system  under 
analysis.  This  statement  provides  explicit  or  implicit  information 
regarding  the  standards  involved. 

•  Discriminatory — Measures  must  discriminate  sufficiently  so  that  real 
differences  among  alternatives  can  be  readily  identified.  Without  this 
measurement  capability,  important  information  can  be  obscured. 

•  Measurable — A  measure  must  represent  a  measurable  concept.  Data 
collection  must  be  possible  in  some  form.  As  a  general  rule,  values  are 
assigned  to  measures  on  the  basis  of  observations  acquired  through  the 
use  of  a  broad  range  of  analytic  tools.  As  in  the  case  of  three  of  our 
MOEs,  the  historical  availability  or  ease  of  acquiring  extensive  data 
necessary  to  quantify  a  measure  often  precludes  assigning  objective 
values. 

•  Quantitative — It  is  preferable  for  ease  in  analysis  that  measures  be 
quantifiable.  For  example,  a  numerical  one-dimensional  measure 
facilitates  both  the  (univariate)  ranking  of  alternatives  and  the  (multi- 
variate) combination  of  measures.  The  process  by  which  the  measures 
are  combined  is  generally  made  easier  (but  certainly  not  trivial)  if  the 
values  of  the  various  measures  can  be  specified  as  numerical 
quantities. 

TABLE  2.  CRITERIA  FOR  EVALUATION  MEASURES  [REF.  5] 


CHARACTERISTICS 

DEFINITION 

Realistic 

Relates  realistically  to  the  C2  system  and  associated 
uncertainties 

Objective 

Can  be  defined  or  derived,  independent  of  subjective 
opinion 

Appropriate 

Relates  to  acceptable  standards  and  analysis 
objectives 

Sensitive 

Reflects  changes  in  system  variables 

Inclusive 

Reflects  those  standards  required  by  the  analysis 
objectives 

Independent 

Is  mutually  exclusive  with  respect  to  other  measures 

Simple 

Is  easily  understood  by  the  user 
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As  an  application  of  the  need  for  mission-oriented  and  discriminatory 
MOEs,  consider  the  fact  that  measures  used  for  communications  acquisition 
management  would  probably  be  inappropriate  for  evaluating  communication 
system  performance  for  jamming  robustness.  With  this  in  mind,  we  don't 
view  the  measures  specified  in  Section  C  as  any  sort  of  super  set,  but  simply  a 
set  that  seems  to  meet  the  need  for  this  particular  application.  A  careful 
review  of  current  and  alternative  measures  would  be  needed  if  a  different 
decision  problem  was  in  question. 

C    SELECTION  AND  SPECIFICATION  OF  MEASURES 

Since  the  actual  system  we  are  concerned  with  does  not  yet  exist  (a  fully 
integrated  SINCGARS  and  VRC-12  family  MAGTF  architecture),  the  only 
approach  to  assigning  values  for  the  MOEs  we  selected  is  through  simulated 
data  and  conditions  and  historical  data  from  existing  systems.  The  process  we 
followed  for  obtaining  the  quantitative  MOEs  from  MCCAAM  is  illustrated 
in  Figure  16. 

The  Measures  of  Effectiveness  (MOEs)  we  use  to  evaluate  the  level  of 
performance  of  distinct  tactical  FM  communication  configurations  in  a  given 
MAGTF  are  listed  below.  ("S"  denotes  MOEs  measured  on  a  qualitative  scale 

while  "Q"  indicates  quantitative  measures  from  MCCAAM  simulation  runs.) 

•  (S)  Network  Construction  (NC) 

•  (S)  Net  Maintenance  (NM) 

•  (S)  Information  Protection  (EP) 

•  (Q)  Timeliness   (T) 

•  (Q)  Protection  from  Jamming  (PJ) 

•  (Q)  Grade  of  Service  (GOS) 

•  (Q)  Radio  Reliability  (R) 
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Figure  16.  Modelled  System  Analysis  [Ref.  5] 

The  seven  MOEs  we  chose  are  a  subset  of  many  that  could  be  included  for 
a  tactical  communications  system.  Only  those  that  met  the  characteristics 
listed  in  section  B  were  selected  for  this  analysis.  Emphasis  was  placed  on 
measures  that  would  discriminate  between  the  radios  of  interest.  For  a  more 
complete  list  of  possible  communication  MOEs,  see  [10]  and  [33]. 

Three  of  the  seven  MOEs  chosen  are  qualitatively  assessed  while  the 
other  four  are  assessed  quantitatively.  The  four  MOEs  judged  to  have  the 
most  significant  impact  in  evaluating  communications  performance  are 
quantitatively  assessed  using  MCCAAM.  Through  the  use  of  our 
communications  model,  we  can  more  adequately  compare  the  major 
differences  between  competing  architectures.  The  remaining  3  MOEs  are 
qualitatively  assessed  using  the  criterion  scale  illustrated  in  Table  3  since  no 
means  currently  exist  to  capture  these  measures  from  the  model.     The 
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baseline  for  the  criterion  scale  listed  in  Table  3  represents  the  minimum  U.S. 

Army  Training  and  Doctrine  Command  (TRADOC)  performance  criteria  for  a 

tactical  FM  communications  system.    This  criteria  is  used  because  the  Army 

has  performed  the  most  extensive  testing  and  analysis  of  current  U.S.  radio 

systems.    Historical  performance  criteria  of  the  AN//VRC-12  series  and  the 

AN/PRC-77   family   radios   are   used   for   the  baseline   value   when   the 

minimum  TRADOC  criterion  is  classified  or  if  the  standard  was  not  available. 

[Ref.  10:p.  70] 

TABLE  3.  CRITERION  SCALE 

Weight  Criteria 

10  Superior  (MOE  is  the  most  important  factor  which  causes  system 

to  outperform  baseline). 

8  Much  more  effective  than  baseline. 

7  More  effective  than  baseline. 

6  Slightly  better  than  baseline. 

5  Baseline. 

4  Slightly  worse  than  baseline  (marginally  acceptable). 

3  Less  effective  than  baseline. 

2  Much  less  effective  than  baseline. 

0  Inferior  (MOE  does  not  meet  minimum  essential  requirements, 

unacceptable). 

D.    DESCRIPTION  AND  RELEVANCE  OF  MEASURES 

The  seven  MOEs  identified  in  the  section  above  will  now  be  examined 
individually  by  definition  and  by  identification  of  those  variables  that  affect 
the  level  of  MOE  assessment.  The  standard  that  is  used  as  a  baseline  for  each 
measure  is  also  identified  for  those  three  measures  not  obtained  through 
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MCCAAM.      Though    not   explicitly    discussed,    the    mission    oriented, 
discriminatory,  measurable  nature  of  the  MOEs  is  illustrated  in  each  case. 
1.     Network  Construction 

a.  Definition 

Network  construction  is  defined  as  those  actions  that  are 
required  to  make  network  frequency  assignments  at  a  decentralized  level,  the 
effort  required  to  train  net  control  station  (NCS)  operators  on  the  procedures 
to  establish  a  net,  and  the  performance  of  the  radio  operator  during  network 
establishment.  In  the  FM  communications  system  described  in  this  thesis, 
the  Brigade  and  Regimental  Communications-Electronics  Officers  are 
responsible  for  managing  frequencies  in  their  designated  geographical  areas. 
The  NCS  operators  control  and  manage  the  operation  of  specific  nets,  and 
radio  operators  are  responsible  for  understanding  and  executing  proper 
network  procedures. 

Technological  advances  are  usually  accompanied  by  an  increase 
in  operational  and  procedural  complexity.  The  Network  Construction  MOE 
is  used  to  discriminate  between  the  operational  and  procedural  complexity 
differences  of  the  AN/VRC-12  radios  and  the  SINCGARS  radios.  It  is  a 
subjective  assessment  of  the  increased  training  effort  required  at  all  levels  of 
operation  within  the  FM  communications  system  to  implement  the  new 
SINCGARS  radios. 

b.  Variables  Affecting  the  Network  Construction  MOE 

The  amount  of  effort  required  to  establish  a  net  can  be 
determined  from  the  amount  of  time  that  it  takes  to  enter  each  radio  station 
into  the  net.   The  variables  that  influence  the  amount  of  time  are  [Ref.  10]  the 
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skill  levels  of  the  radio  operators,  NCS  operators,  and  communications 
officers,  the  amount  of  training  that  they  have  received,  the  complexity  of  the 
equipment,  and  the  procedural  complexity  of  operation. 

A  subjective  evaluation  of  this  MOE     will  be  made  with  the 

following  assumptions: 

•  The  administrators  and  users  of  the  FM  communications  system  have 
an  average  skill  level  compared  to  all  Marines. 

•  The  complexity  of  equipment  and  procedural  operation  determines  the 
amount  of  required  training. 

c.  Baseline  Criteria 

The  amount  of  time  required  to  train  general  purpose  users  on 
AN/VRC-12  series  radios  is  used  as  a  baseline  criteria.  Specific  figures  for 
testing  requirements  and  scores  collected  by  various  Army  testing  agencies 
are  detailed  in  [Ref.  10]. 

d.  Alternative  Radio  Assessments 

The  following  findings  and  observations  were  used  to  make  a 
subjective  evaluation,  and  determine  criteria  scores  for    the  alternative  radio 

configurations  examined  in  this  thesis. 

•  Electromagnetic  Compatibility  Analysis  Center  (ECAC)  personnel  feel 
that  the  electronic  remote  fill  (ERF)  capability  of  the  frequency-hopping 
radio  requires  an  NCS  operator  with  special  training  commensurate 
with  an  additional  skill  identifier.  They  cite  the  SINCGARS-V 
Maturity  Operational  Test  (MOT)  [Ref.  35]  as  an  example  where  there 
was  a  high  net  establishment  failure  rate,  and  some  net  operators  with 
a  rank  of  E-6  took  as  long  as  eight  hours  to  give  all  stations  in  the  net 
the  correct  ERF  variable.  [Ref. 10:  p  87] 

•  SINCGARS  NCS  operators  need  a  higher  skill  level  and  require  more 
intensive  and  repetitive  training  that  normal  radio  operators. 

•  SINCGARS  frequency-hopping  operator  skills  require  extensive  hands- 
on  training  to  acquire,  and  repetitive  application  to  retain. 
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•  Net  establishment  times  have  been  reduced,  however  the  times  still 
remain  greater  than  for  single-channel  operation.  Operators  are  not 
able  to  commit  frequency-hopping  skills  to  memory  because  of  their 
complexity  and  number  of  precise  actions  required  to  complete  them. 

•  The  49  SINCGARS  radio  human  engineering  problems  identified 
during  the  MOT  will  unnecessarily  increase  training  time  and 
requirements. 

The  MOE  criterial  score  for  each  radio  alternative  configuration 
is  based  on  the  information  presented  in  this  section.  The  values  were 
obtained  from  MOP  utility  values  published  in  the  Concept  Formulation 
Package  for  SINCGARS  [Ref.  3].  The  results  from  testing  the  AN/VRC-12 
radio  represent  the  baseline  criteria  for  the  Network  Construction  MOE. 

DESCRIPTION  SCORE 

Conventional  Single-Channel  FM  w/COMSEC1  5 

SINCGARS-V  w/imbedded  COMSEC,  Frequency  Hopping  3 

Mixed  SINCGARS  and  Conventional  FM  Environment  3-5 

The  criteria  score  for  the  mixed  environment  is  determined  by 
the  number  of  subscribers  on  SINCGARS  nets  and  the  number  of  subscribers 
on  conventional  AN/VRC-12  series  nets. 

For  example,  if  60  percent  of  an  architecture's  nets  were 
conventional  fixed-frequency  nets  and  this  totaled  120  fixed-frequency 
subscribers,  then  each  of  those  subscribers  would  have  to  join  its  given  net 
with  a  score  of  5.  If  the  other  40  percent  were  SINCGARS  nets  with  80 
subscribers,  then  each  of  the  SINCGARS  subscribers  would  be  able  to  join 


1  COMSEC  refers  to  Communications  Security  equipment  which  encrypts 
messages  before  they  are  transmitted. 
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their  nets  with  a  lower  score  of  3  to  reflect  a  more  complex,  time-consuming 
net  construction  process. 

The  resulting  Network  Construction  MOE  would  be: 
(120)*5  +  (80)*3  =  840/200  subscribers  =  4.2 

and  would  reflect  the  fact  that  this  architecture  was  closer  to  the  baseline 
standard  of  5.0  than  the  all-SINCGARS  architecture  score  of  3.0. 
2.     Network  Maintenance 

a.  Definition 

The  Net  Maintenance  MOE  is  the  measure  of  the  administrative 
traffic  that  is  required  to  retain  network  connectivity  after  the  net  has  been 
established.  Examples  of  administrative  traffic  are  radio  checks,  frequency 
changes,  and  net  procedural  traffic. 

b.  Variables  Affecting  the  Net  Maintenance  MOE 

The  tactical  and  environmental  situation,  the  probability  that 
COMSEC  and  frequency-hopping  operational  variables  will  be  lost,  and  the 
degree  of  confidence  that  the  NCS  has  in  the  equipment  and  its  operators  are 
all  variables  that  affect  the  amount  of  time  an  NCS  must  dedicate  to 
maintaining  a  given  net. 

To  compare  alternative  radio  configurations,  this  thesis  will 
only  consider  the  loss  of  essential  radio  variables  to  assess  Net  Maintenance. 
It  is  recognized  that  the  tactical  situation  and  environmental  factors  can 
change  the  degree  of  net  maintenance,  however  the  change  will  be  primarily 
relative  to  the  situation,  and  not  to  the  radio  configuration  employed. 
Similarly,  the  variable  of  confidence  is  likely  to  change  from  unit  to  unit,  so  it 
is  not  considered  in  developing  this  MOE.  (Here  we  could  incorporate  a  factor 
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that  distinguishes  the  greater  training  and  availability  c '  knowledgeable 
operators  at  higher  unit  levels) 

c.  Baseline  Criteria 

The  net  operation  of  the  AN/VRC-12  series  radio  is  used  as  the 
baseline  criteria  from  which  to  make  qualitative  assessments  of  utility 
rankings  for  alternative  radio  configurations. 

d.  Alternative  Radio  Assessments 

Since  the  AN/VRC-12  series  radio  and  SINCGARS  radio  will 
use  similar  COMSEC  devices,  the  loss  of  this  equipment  variable  is  not 
addressed.  Everything  else  remaining  equal,  the  SINCGARS  frequency- 
hopping  radio  has  five  additional  equipment  variables  required  to  insure 
proper  operation  in  the  frequency-hopping  mode.  These  additional  variables 
were  described  in  section  C  of  Chapter  n. 

Below  are  the  results  of  the  Maturity  Operational  Test  and 
Operational  Assessment  (O/A)  showing  the  average  number  of  times  that  a 
radio  experienced  the  loss  of  one  or  all  of  the  frequency-hopping  variables 
[Ref.  10:  p.  1]. 

PROBLEM  MOT  RESULTS        O/A  RESULTS 

Loss  of  variables       21 /week/radio        1.4 /week /radio 

When  these  SINCGARS  variables  are  lost  for  whatever  reason, 
the  recovery  process  is  quite  time  consuming  and  can  take  from  thirty  to  fifty 
steps  to  reload  the  lost  variables  [Ref.l0:p.  13].  Since  radios  using  the  fixed- 
frequency  mode  of  operation  do  not  require  these  five  variables,  performance 
in  terms  of  increased  administrative  time  is  reduced.    Therefore,  the  Net 
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Maintenance  MOE  receives  a  marginally  acceptable  criteria  score  of  4  for 
alternatives  employing  frequency-hopping  operation.  The  criteria  score  for 
the  mixed  radio  configuration  is  determined  by  a  percentage  of  SEMCGARS 
and  fixed  frequency  nets  in  the  given  architecture  as  demonstrated 
previously. 

DESCRIPTION  SCORE 

Conventional  Single-Channel  FM  w/COMSEC  5 

SINCGARS-V  w/imbedded  COMSEC,  Frequency  Hopping  4 

Mixed  SINCGARS  and  Conventional  FM  Environment  4-5 

3.     Information  Protection  (IP) 

a,  Definition 

The  Information  Protection  MOE  is  defined  as  the  effectiveness 
of  the  design  parameters  that  have  been  built  into  the  network's  radio 
equipment  that  allows  it  to  conceal  transmitted  information  from 
unauthorized  users.  It  is  a  measure  of  the  architecture's  electronic  counter- 
countermeasure  (ECCM)  ability. 

This  MOE  is  often  used  with  an  ECCM  encryption  MOE  which 
would  be  assessed  by  comparing  information  scrambling  (COMSEC) 
techniques  and  devices. 

b.  Variables  Affecting  Information  Protection  MOE 

The  design  parameters  of  antennas,  the  power  output  control 
parameters,  and  the  frequency  modulation /spread  spectrum  techniques 
employed  by  the  radio  technology  are  the  variables  used  to  develop  a 
Information  Protection  (IP)  MOE  assessment. 
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All  of  these  design  parameter  variables  can  be  used  to  conceal 
the  transmitted  information  from  unauthorized  users.  Directional  antennas 
transmit  a  signal  in  only  one  limited  sector  forward  of  friendly  position,  thus 
reducing  the  chance  of  detection  by  the  enemy.  Power  output,  when  reduced 
to  the  minimum  strength  necessary  to  establish  a  link,  will  also  reduce  the 
probability  of  being  detected  by  the  enemy  because  the  transmission  range  is 
reduced. 

The  most  important  variable  required  to  assess  the  IP  MOE  is  the 
frequency-hopping  capability  of  the  new  radio  systems.  The  information 
transmitted  over  a  frequency-hopping  radio  (when  hopping  more  than  200 
hops  per  second)  cannot  be  captured  by  unauthorized  users  unless  they  know 
the  exact  hopping  pattern  and  hopping  rate,  and  can  synchronize  equipment 
to  receive  these  transmitted  signals. 

c.  Baseline  Criteria 

The  conventional  single-channel  FM  radio  configuration  is  used 
as  a  baseline  measurement. 

d.  Alternative  Radio  Assessments 

Alternative  one  has  a  criteria  score  of  five  as  the  baseline.  The 
AN/VRC-12  series  radios  can  transmit  on  a  low  power  setting  of  3-5  watts, 
and  are  capable  of  using  directional  long  wire  antennas  cut  to  the  desired 
frequency. 

DESCRIPTION  SCORE 

Conventional  Single-Channel  FM  w/CRYPTO  5 

SINCGARS-V  w/imbedded  CRYPTO,  Frequency  Hopping  9 

Mixed  SINCGARS  and  Conventional  FM  Environment  5-9 
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SINCGARS  operating  in  the  fixed-frequency  mode  would  have  a 
slight  advantage  over  the  conventional  system  in  that  power  output  can  be 
adjusted  down  to  four  watts.  This  feature  allows  the  SINCGARS  fixed- 
frequency  user  to  have  more  flexibility  in  providing  protection  for  his 
transmitted  message. 

The  frequency-hopping  capability  of  the  SINCGARS  radio 
provides  state-of  -the-art  protection  against  unauthorized  users  intercepting  a 
transmitted  message.  This  alternative  did  not  receive  a  utility  rating  of  10  for 
the  IP  MOE  because  the  efficiency  of  directional  antennas  is  decreased  in  the 
frequency-hopping  mode  of  operation.  Antennas  are  adjusted  for  one  specific 
frequency.  They  cannot  provide  maximum  efficiency  for  frequency-hopping 
radios  which  transmit  multiple  frequencies  over  one  channel.  The  criteria 
score  for  the  mixed  environment  is  determined  by  the  percentage  of 
SINCGARS  radios  and  conventional  AN/VRC-12  series  radios  assigned  to 
the  same  unit.  For  example,  if  60  percent  of  a  force's  radios  were  conventional 
fixed-frequency  and  the  other  40  percent  were  SINCGARS,  then  the  resulting 
force  IP  MOE  would  be:  (.60)*5  +  (.40)*9  =  6.6. 
4.  Radio  Reliability  (R) 
a.     Definition 

Though  we  initially  intended  to  develop  a  measure  of  overall 
system  reliability  (an  additional  MOE  that  could  be  used  to  discriminate 
between  architectures)  time  prevented  us  from  including  that  in  the  current 
version  of  MCCAAM.  Instead  of  calculating  some  measure  of  overall  system 
reliability,  we  simply  collect  the  number  of  radio  failures  for  each  type  of 
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radio  in  a  given  architecture.   The  total  failures  for  an  architecture  give  some 
indication  of  reliability  at  the  component  level. 

MCCAAM  collects  radio  failure  statistics  on  all  the  individual 
radio  objects  (AN/VRC-12  family  or  SINCGARS)  throughout  the  simulation 

run.   Assumptions  in  the  collection  of  this  data  include: 

•  Radio  equipment  configurations  and  operations  are  in  accordance  with 
published  operating  instructions. 

•  All  the  radios  of  same  type  have  the  same  MTBF. 

b.  Variables  Affecting  the  Reliability  MOE 

The  assumptions  made  in  modelling  radio  reliability  (i.e. 
exponential,  no  wear-out  lifetimes)  preclude  anything  within  the  current 
model  environment  from  really  affecting  the  reliability  measure.  We 
understand  that  we  are  simply  sampling  failure  times  from  an  exponential 
distribution  and  then  collecting  those  failures.  The  only  factor  influencing 
the  number  of  failures  within  a  simulation  run  is  the  user  defined  MTBF 
values  for  the  various  radio  types. 

c.  Alternative  Radio  Assessments 

Recent  upgrades  and  redesign  have  greatly  increased  the  MTBF 
factor  for  the  SINCGARS  from  an  initial  value  of  1250  hours.  For  example,  a 
1988  follow-on  operational  test  and  evaluation  (FOT&E)  demonstrated  an 
MTBF  exceeding  5,000  hours  for  100  radios  in  operation  for  over  20,000 
operating  hours  [Ref.  37].  More  recently,  preliminary  reports  from  the  Gulf 
War  proclaim  SINCGARS  MTBFs  were  around  the  7,000  hour  mark, -whereas 
the  VRC-12  family  of  radios  experienced  an  MTBF  average  range  of  250  -  300 
hours.  Using  the  definitions  and  equations  outlined  above,  MCCAAM 
allows   an  assessment  of  radio  reliability  for  any  given  mixed   radio 


86 


environment  by  randomly  generating  reliability  failures  and  repairs  from 
exponential  distributions  with  appropriate  means  from  recent  test  results  and 
then  aggregating  the  results  for  all  the  radios  in  the  system. 
5.     Grade  of  Service  (GOS) 
a.     Definition 

The  probability  that  a  message  that  is  transmitted  from  an  FM 
communications  station  is  received  by  the  intended  recipient.  This  will  be 
assessed  quantitatively  in  MCCAAM  by  tracking  the  number  of  message 
transmission  attempts  and  completions  by  each  radio.  The  percent 
transmissions  completed  will  reflect  this  measure. 

GOS  =  (#  messages  completed/#  messages  attempted)  *  100.0 

As  in  all  aspects  of  modelling  a  complex  system,  definitions  are 
key  to  implementation  of  a  process.    For  collecting  statistics  from  the  myriad 

of  radios  in  a  MCCAAM  run,  the  following  definitions  were  used: 

•  Attempt:  any  time  that  a  radio  tries  to  perform  the  acknowledgement 
and  transmission  sequence  with  another  radio. 

•  Success:  an  attempt  that  culminates  in  the  information  transferred  to 
the  intended  receiver  radio  (note  distinction  between  intended  receiver 
and  destination  of  message  for  the  case  where  a  message  is  routed 
through  an  alternate  net) 

Thus,  a  radio  which  attempts  to  transmit  a  MEO  to  two  receivers 

in  which 

•  receiver  1  acknowledges  contact,  receives  full  transmission,  and 
acknowledges  receipt  would  be  counted  as  (1  attempt,  1  success) 

•  receiver  2  does  not  acknowledge  contact  until  the  transmitter  has 
pursued  the  acknowledge  process  two  times  and  then  acknowledges 
contact  and  receives  full  transmission.  This  would  be  counted  as  (3 
attempts,  1  success). 
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6.     Protection  from  Jamming  (PJ) 

a.  Definition 

Electronic  countermeasures  (ECM)  is  defined  [7]  as  those  actions 
taken  to  reduce  effective  use  of  the  electromagnetic  spectrum.  These  actions 
include  jamming,  electronic  deception,  and  emitter  direction  finding. 

Of  the  three  major  areas  mentioned  above,  only  jamming  will 
be  considered  in  the  evaluation  of  the  jamming  protection  MOE.  The 
vulnerability  of  a  given  radio  configuration  to  direction  finding  (DF)  can  be 
represented  by  an  equation  taking  into  account  such  factors  as  power  output, 
transmitter  and  receiver  antenna  gain,  thermal  noise,  environmental  noise, 
and  path  loss  of  the  signal,  but  these  factors  are  not  currently  incorporated 
into  MCCAAM.  [Ref.  10] 

b.  Variables  Affecting  the  Protection  from  Jamming  MOE 

An  equation  that  represents  how  well  a  given  architecture 
continues  to  function  when  it  is  being  jammed  by  enemy  electromagnetic 
activity  is: 

PJ   =  GOSj/GOS 

where: 

PJ  =  Assessment  of  architecture's  resistance  to  jamming 

GOSj  =   Average  link  grade  of  service  during  jamming 

GOS  =   Average  link  grade  of  service  before  jamming 

c.  Alternative  Radio  Assessments 

MCCAAM  is  used  to  measure  the  effects  of  jamming  by  running 
a  given  scenario  and  collecting  required  data  to  calculate  the  grade  of  service 
(GOS)  for  that  architecture.     A  user  specified  level  of  jamming  is  then 
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introduced  and  the  simulation  is  run  again  with  the  same  traffic  workload 

sample  path.  The  grade  of  service  is  calculated  and  the  difference  is  attributed 

to  the  jamming  effect  on  the  communications  architecture. 

7.     Timeliness  (T) 

a.     Definition 

Timeliness  is  described  by  the  average  amount  of  time  a  message 

has  to  wait  for  delivery  by  a  given  architecture.  We  calculate  average  message 

wait  time  as  the  difference  in  message  delivery  time  and  message  duration. 
W    =  average  message  wait  time 
W    =   Message  Delivery  Time-Message  Duration 
W    =   (Msg  Stop  Time-Msg  Start  Time)-Msg  Duration 

We  define  the  message  delivery  time  as  beginning  when  a 
message  is  pulled  out  of  its  radio  queue  and  a  transmission  is  attempted.  The 
completion  time  is  defined  when  a  message  is  successfully  received  by  its 
intended  receiver.  So,  for  a  single  simulation  run,  each  radio  will  have  its 
own  average  message  delivery  time.  By  defining  timeliness  in  this  manner, 
we  take  into  account  the  fact  that  different  radios  will  be  processing  different 
BOSTS  with  different  message  durations. 

After  we  calculate  each  radio's  average  message  wait  time,  we 
sum  over  each  type  of  radio  to  obtain  an  average  message  wait  time  by  radio 
type.  We  then  aggregate  to  the  architecture  level  and  obtain  an  overall 
average  message  wait  time. 

Since  an  architecture's  average  message  wait  time  will  depend 
greatly  on  the  amount  of  traffic  it  handles,  we  need  to  scale  the  average 
message  wait  time  by  the  number  of  messages  successfully  transmitted. 
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W*  =  Adjusted  W  =  W/#  Messages 

Our  Timeliness  MOE  is  then  defined  as  one  over  the  adjusted  wait  time.   This 
convention  makes  the  larger  valued  MOE  more  desirable. 

T  =  1/W* 

b.  Variables  Affecting  Timeliness 

Any  network  subjected  to  any  type  of  stresses  at  all  will  not  be 
able  to  process  traffic  in  a  perfectly  timely  manner.  In  MCCAAM,  the  stresses 
of  jamming,  radio  failures,  and  heavy  contention  for  a  given  net  all 
contribute  to  a  message  not  being  transmitted  in  exactly  its  message  duration 
time.  For  example,  suppose  a  battalion  Fire  Support  Coordination  Net  radio 
pulls  its  top  priority  message  out  of  its  queue  and  attempts  to  transmit  it  to  a 
jammed  intended  receiver.  That  message's  delivery  time  will  incorporate  all 
the  waiting,  re-trials,  and  possible  re-routing  time  that  is  necessary  to  get  the 
message  to  the  intended  receiver. 

c.  Alternative  Radio  Assessments 

The  average  message  delivery  time  is  collected  by  radio  type,  so 
comparisons  between  radio  types  within  a  given  architecture  are  available. 
Since  the  SINCGARS  radios  have  a  smaller  MTBF  and  are  essentially  jam- 
proof,  the  average  message  delivery  time  will  be  lower  for  a  SINCGARS  radio 
when  compared  to  a  PRC-77  radio  in  the  same  communications 
environment.  Because  some  messages  have  much  longer  transmission  times 
than  others,  a  SINCGARS  radio  might  have  a  longer  average  message  time 
than  a  PRC-77  if  it  processed  many  BOSTS  with  longer  than  average  message 
lengths.    For  this  reason,  the  message  durations  were  all  set  to  an  arbitrary 
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four  minutes  in  duration  for  our  comparative  analysis.  As  a  result  of  this 
control  over  the  simulation,  we  can  confidently  attribute  any  variations  in 
average  message  time  to  different  radio  types. 

E     AGGREGATION  APPROACH 

The  common  problem  is  this:  given  a  set  of  MOEs  mi,  m2,  n\3,  ...,  mn  we 
wish  to  combine  them  into  an  overall  MOE,  E.    There  are  traditionally  two 

approaches  to  this  problem  [26]: 

•  Define  E  by  some  mathematical  function 

•  Develop  the  relationship  of  E  and  m-\,  m2,  nvj,  ...,  mn  using  expert 
judgment 

When  the  first  approach  is  used,  the  most  common  method  is  to  assume 

a  linear  combination: 

E  =  wjmi  +  W21T12  +  W3m3  +  ...  +  Wnmn 

where  the  w's  are  relative  measure  weights  which  reflect  the  amount  of 
importance  attributed  to  each  measure  by  the  user  or  modeler.    The  positive 

features  of  this  approach  are: 

•  Simple,  easier  to  sell  than  other  approaches. 

•  No  data  needed  to  build  the  relationships  except  the  weights. 

and  the  negative  features  are  [26]: 

•  It  is  an  arithmetic  average  of  the  measures  and  hard  to  justify  the 
averaging  idea. 

•  Substitutability  (often  unwanted)  exists  in  that  while  relationships 
should  evaluate  tradeoffs,  the  trade-off  should  be  designed  in  and  not 
there  as  a  whim  of  the  function. 

•  This  approach  does  not  provide  diminishing  marginal  return  (second 
derivative  <  0) 

•  Unresolved  dimensionality  problems  almost  always  exist  ...  i.e. 
combining  time,  number  of  messages,  penalty  rates,  etc. 
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•  No  consideration  of  variance  (or  recognition  of  uncertainty)  in  the 
measuring  process. 

•  This  approach  gives  E  by  definition  and  is  not  an  approximation  to  a 
real  world  number;  therefore,  we  cannot  test  it. 

•  Assumes  the  MOEs  are  mutually  exclusive  in  what  they  measure! 

To  avoid  some  of  the  pitfalls  described  above,  we  have  decided  to  use  a 
variation  of  the  linear  combination  approach  where  E  is  defined  as  the 
weighted  linear  combination  of  the  utilities  of  the  given  measures,  where 
the  utilities  are  measured  on  a  0-1  scale. 

This  approach  handles  the  diminishing  marginal  return  problem  and 
this,  in  turn,  helps  a  bit  with  the  basic  substitutionality  problem.  It  also 
alleviates  the  dimension  problem,  but  it  is  still  an  average  and  there  is  still  no 
consideration  of  variance  on  the  weights  assigned. 

For  such  a  small  number  of  MOEs,  we  have  elicited  the  weights  to  be 
used  in  the  aggregation  from  select  experts  by  having  them  use  a  commercial 
software  product,  Expert  Choice  [Ref.  39],  to  make  paired  comparisons  of  the 
MOEs  (each  MOE  is  compared  against  every  other).  The  Analytical  Hierarchy 
Process  (AHP)  used  by  Expert  Choice  is  a  well  known  procedure  which 
derives  relative  scales  using  judgments  from  experts  in  the  form  of  these 
paired  comparisons.  AHP  background  and  examples  can  be  found  in  [38]. 

The  first  step  in  using  Expert  Choice  is  the  structuring  of  the  problem  as  a 
hierarchy  of  nodes  or  leaves.  Figure  17  illustrates  our  problem  levels.  The 
first  (or  top)  level  is  the  overall  goal.  In  our  case,  it  is  the  selection  of  the  best 
communications  architecture.  In  the  second  level  we  have  three  categories 
which  contribute  to  the  goal.    Each  of  the  three  categories  has  two  or  more 
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MOEs,  or  criteria,  beneath  them  to  form  level  three.  The  second  step  is  where 
each  expert  is  asked  to  make  decisions  about  the  relative  importance  of  each 
MOE  (as  compared  to  each  other  MOE)  with  respect  to  the  overall  goal  of 
selecting  the  best  architecture.  This  judging  is  conducted  in  a  structured 
environment  in  Expert  Choice  where  the  decision  maker  is  presented  with  a 
sequence  of  all  possible  MOE  pairs. 


Select  Best  Comm.  Architecture 


GOAL 
L  1.000 


PROTECT 
L  0.293 


STRUCT 
L  0.174 


SERVICE 
L  0.533 


-ANTI -JAM 
L  0.500 

-DATAPROT 
L  0.500 


-RELIABIL 
L  0.614 

-NETCONST 
L  0.268 

-NETMAINT 
L  0.117 


-TIMELINS 
L  0.640 

-GOS 
L  0.360 


Figure  17.  Problem  Hierarchy 

Once  all  possible  pair-wise  comparisons  have  been  made  within  each 
level,  Expert  Choice  produces  the  unique  MOE  weights  based  on  the 
comparisons  made  by  the  expert.  Figure  18  shows  one  of  the  many  forms  out 
output  that  Expert  Choice  provides  in  the  form  of  a  sorted  synthesis  of  the 
leaf  nodes  with  respect  to  the  overall  goal  of  selecting  the  best  architecture. 
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The  consensus  on  the  order  of  importance  for  the  seven  MOEs    and  the 
accompanying  weights  assigned  are  as  follows: 

MOE 

(GOS)    Grade  of  Service 


(PJ) 
(T) 
(R) 


Protection  from  Jamming 

Timeliness 

Radio  Reliability 
(NM)     Network  Maintenance 
(IP)         Information  Protection 
(NC)      Network  Construction 


WEIGHT 

0.299 
0.191 
0.176 
0.141 
0.084 
0.064 
0.045 


Sorted 

Select 

Synthesis  of 

OVERALL 

GOAL 

Best  Comm.  Architecture 
Leaf  Nodes  with  respect  to 
INCONSISTENCY  INDEX  -   0.00 

1.000 

Figure  18.  Sorted  Synthesis  of  Leaf  Nodes 

1.     Utility  Theory  „ 

"If  a  man  will  begin  with  certainties,  he  shall  end  in  doubts;  but  if  he 
will  be  content  to  begin  with  doubts  he  shall  end  in  certainties." 

Francis  Bacon 
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MCCAAM  users  will  most  likely  be  using  the  simulation  model  to 
help  select  one  alternative  out  of  several.  When  the  alternatives  lead  to 
payoffs  that  are  random,  one  would  like  to  select  the  alternative  for  which 
the  expected  mean  value  of  the  payoff  is  the  largest,  but  many  decisions  are 
too  complex  to  make  decisions  by  comparing  payoff  averages  directly. 

Decisions  can  be  simplified  though,  provided  payoffs  are  measured  by 
their  utilities.  Von  Neumann  and  Morgenstern  [1944]  showed  that  if  a 
decision  maker  is  rational2,  there  exists  a  function  U  (the  decision  maker's 
utility  function)  having  the  property  that  the  best  alternative  is  the  one  for 
which  the  expected  utility  is  largest.  In  other  words,  a  rational  decision  maker 
will  make  decisions  as  if  he  were  ranking  them  by  expected  utility,  even  if  he 
never  actually  makes  the  computation.  Personal  preferences  enter  through 
utility  functions.  Utility  functions  can  be  measured,  but  we  will  not  discuss 
methods  for  eliciting  the  utility  functions  of  actual,  human  decision  makers 
in  this  thesis.  Utility  functions  will  always  be  assumed  to  be  known, 
sometimes  with  an  argument  as  to  plausibility. 

If  U'  =  aU  +  b,  then  the  linearity  of  the  expectation  operator  implies 
that  E(U')  =  aE(U)  +  b.  It  follows  that  E(U')  and  E(U)  rank  alternatives  in  the 
same  order  as  long  as  a>0,  and  therefore  that  U'  is  operationally  the  same 
utility  function  as  U.    Therefore  the  origin  and  unit  of  utility  can  be  selected 


2  "Rational"  means  that  certain  postulates  of  rationality  are  satisfied. 
Rational  decision  makers,  for  example,  are  assumed  to  have  transitive 
preferences:  if  A  is  preferred  to  B  and  B  to  C,  then  A  must  be  preferred  to  C. 
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for  convenience — letting  the  worst  outcome  have  a  utility  of  0  and  the  best  a 
utility  of  1.0  is  common. 

Figure  19  illustrates  the  characteristics  of  the  three  basic  utility 
preference  curves:  risk  averse,  risk  neutral,  and  risk  prone.  The  real  value,  or 
utility  of  an  additional  increment  of  a  measure  of  effectiveness  depends  on 
how  much  you  already  have. 


Utility 


1.0     - 


0.5     - 


Risk  Averse 


Risk  Prone 


Figure  19.  Utility  Curve  Classifications 

The  risk  averse  decision  maker  exhibits  a  diminishing  additional 
utility  for  increasing  levels  of  the  item  of  interest,  once  beyond  a  given  point. 
As  an  example,  the  log  function,  y  =  log  x,  is  concave  downward,  consistent 
with  the  idea  of  diminishing  additional  utility  as  one's  wealth  increases  from 
each  increment  of  added  money.    The  risk  neutral  decision  maker  exhibits  a 


96 


linearly  increasing  utility  for  increasing  levels  of  the  item  or  quantity  of 
interest.  The  risk  prone  decision  maker  exhibits  a  rapidly  increasing  utility  for 
increasing  levels  of  the  quantity  of  interest. 

To  illustrate  the  use  of  utilities  with  respect  to  our  measures  of 
effectiveness,  an  example  is  presented  for  the  qualitatively  assessed  Network 
Construction  MOE. 

For  each  net  in  a  given  architecture,  the  criterion  scale  values  defined 
by  Table  3  are  assigned.  Next,  for  each  type  of  net  in  the  architecture  the  scale 
values  are  summed  and  then  divided  by  the  total  number  of  nets.  This  gives 
the  architecture's  Network  Construction  score,  which  is  then  applied  to  the 
decision  maker's  specified  utility  curve. 
Example:   Given  200  MEB  Single-Channel  Nets 

140  Conventional    *    Scale  Value  of  5      =       700 

60  SINCGARS     *    Scale  Value  of  3      =        180 

880 

Dividing  the  sum  of  880  by  total  number  of  nets,  200,  yields  4.40, 
which  is  this  architecture's  raw  Network  Construction  score. 

Assuming  a  risk  prone  utility  curve,  U(x)  =  x^,  we  see  (Figure  20)  that 
the  utility  of  a  Network  Construction  value  of  4.4  is  0.194  when  the  baseline 
value  of  5.0  would  give  a  utility  of  0.25. 
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J 
1.0  - 

i   100 

Risk  Prone 

100 

2  1 
U(x)  =  x   1 

19.36 

100 

0.194 

1 s^-i-l |— 

4.4  5          10 

Figure  20.  Utility  of  Network  Construction  MOE 

Clearly,  the  choice  of  utility  curve  as  well  as  the  choice  of  weighting 
and  criterion  scale  for  the  subjective  MOEs  will  have  definite  impacts  on  the 
calculated  utilities.  When  the  same  decision  environment  must  be  faced  on 
multiple  occasions,  ranking  outcomes  according  to  expected  utility  is 
definitely  a  more  comfortable  idea,  but  there  is  no  logical  requirement  for  that 
to  be  the  case. 

The  assumption  that  the  seven  MOEs  are  mutually  exclusive  is  one 
that  could  be  argued  against  fairly  easily,  and  if  a  decision  maker  doesn't  like 
that  approach,  the  individual  MOEs  can  be  assessed  individually  for  each 
architecture  examined. 
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F.     PENALTY  PROCESS 

A  more  direct  way  to  measure  the  overall  effectiveness  of  a  given 
communications  network  is  through  a  unique  penalty  accrual  process  we 
have  developed  which  is  directly  related  to  the  system's  timeliness. 
Timeliness,  of  course,  is  affected  by  all  the  previous  MOEs  in  some  manner  or 
another,  and  thus  is  a  good  natural  aggregation  measure. 

Each  BOST  which  is  undertaken  has  a  time  within  which  all  of  the  tasks 
associated  with  it  (MEOs)  must  be  completed.  As  described  in  Chapter  III, 
these  times  are  not  available  from  any  doctrinal  source,  so  professional  best 
guess  values  were  specified  based  on  fleet  experience  in  the  Marine  Corps. 
These  values  are  some  of  the  many  available  for  easy  manipulation  within 
MCCAAM.  Since  these  times  are  common  to  architectures  being  compared 
in  MCCAAM,  and  no  real-world  values  exist,  only  their  magnitudes  relative 
to  one  another  are  of  any  importance. 

If  a  given  BOST  is  not  completed  within  its  user-defined  allotted  time,  a 
one-time  penalty  is  recorded.  This  penalty's  value  is  determined  by  the 
nature  of  the  BOST  and  the  particular  unit  that  is  originating  it.  Additionally, 
some  designated  BOSTs  will  continue  to  accrue  additional  penalties  for  each 
time  unit  they  proceed  beyond  their  given  allotted  times.  Collectively,  these 
penalties  reflect  the  system's  ability  or  inability  to  process  traffic  in  a  timely 
manner.  [Ref.  11] 

The  stationary  mean  rate  of  penalty  accrual  will  reflect  the  degree  to 
which  the  network  is  functioning  properly.  If  a  large  amount  of  penalty  is 
being  accumulated  constantly,  the  BOST  deadlines  are  consistently  being 
violated.    The  analyst  or  model  user    then  identifies  the  sources  of  largest 
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consistent  penalty  accrual  and  determines  if  the  given  deadlines  are 
unrealistic,  if  certain  nets  or  units  are  consistently  resource  constrained,  or  if 
some  BOSTs  need  to  be  redesigned.  By  analyzing  the  penalty  choke  points, 
an  analyst  might  improve  the  doctrinal  structure  for  a  given  BOST  by 
increasing  task  concurrency  or  changing  traffic  routing  to  ensure  more  timely 
dissemination. 

Beyond  the  stationary  mean  rate  of  penalty  accrual  mentioned  above,  we 
know  that  to  fully  stress  a  given  network  architecture,  we  would  need  to  test 
many  different  traffic  intensity  patterns  before  we  found  one  to  break  the 
network.  By  linearly  increasing  the  traffic  workload  intensity,  we  can  obtain  a 
measure  of  effectiveness  that  is  less  straightforward  than  the  stationary  case 
but  one  that  provides  some  very  good  insights  into  network  performance. 
Recall  that  in  our  central  traffic  generation  process  described  in  section  C  of 
Chapter  IE,  the  delays  between  BOST  generations  had  a  mean  2/Ar.  We  will 
call  r  our  workload  intensity,  and  we  consider  the  case  r-1  to  be  our  baseline. 
As  previously  discussed,  the  BOST  initiation  rates  do  not  come  from  any 
doctrinal  or  scenario  specific  source  and  thus  do  not  reflect  an  actual  system's 
fluctuating  intensity.  Any  given  real-time  communications  network's  traffic 
is  going  to  be  highly  dependent  on  the  level  of  unit  engagements,  movement, 
enemy  EW  action,  the  time  of  day,  and  the  terrain  and  weather.  Not  wanting 
to  be  tied  to  a  scenario  or  attrition  type  model,  we  allow  the  traffic  intensity  to 
continuously  increase  over  time  to  give  a  picture  of  network  performance 
through  all  ranges  of  possible  stress. 

When  we  use  r  as  our  workload  intensity  variable,  we  believe  that,  for 
each  communications  configuration,  there  exists  a  threshold  workload 
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intensity  r*  such  that  for  r  <  r*,  the  penalty  accumulating  rate,  3p(r)/3r,  is 
fairly  small,  and  as  the  workload  intensity  grows  above  r*,9p(r)/9r  rapidly 
becomes  much  large.  Thus  a  communications  network  can  handle  its 
workload  fairly  well  until  the  workload  intensity  passes  r*,  at  which  point 
the  system  breaks  and  can  no  longer  handle  the  offered  traffic.  Analysis  of 
this  increasing  workload  intensity  is  not  covered  in  this  thesis. 

To  summarize,  our  penalty  MOE  (P)  is  the  sum  of  all  one-time  penalties 
and  accrued  penalty  rate  for  a  given  simulation  run.  Since  the  overall 
penalty  will  be  a  direct  function  of  the  number  of  BOSTS  that  get  processed, 
we  scale  the  accumulated  penalty  by  that  number  of  BOSTS.  This  provides  a 
more  accurate  relative  measure  of  an  architecture's  penalty. 

P*  -  P/#  BOSTS 

G.    SUMMARY 

In  most  simulation  programs,  model  parameters,  when  related  to 
physical  entities,  are  as  objective  and  quantified  as  they  would  be  in  an 
engineering  sense,  and  can  be  measured  or  estimated.  When  equipment 
parameters  have  not  been  clearly  defined  for  all  ranges  of  a  system  or  are 
unavailable,  measures  of  performance  (MOP)  for  these  items  are  not  as  easily 
measured.  In  these  cases,  MOP's  are  often  subjective  and  qualitative,  e.g., 
ordinal  ranking  by  experts,  and  may  or  may  not  be  assigned  numerical  values. 
MOEs  and  MOFEs  are  heavily  judgmental  even  when  they  are  numerical, 
since  choosing  system  boundaries,  particular  functions  to  be  evaluated,  and 
the  reference  standards  can  greatly  influence  particular  numerical 
calculations.     When  based  on  models,  they  are  highly  dependent  on  the 
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model  assumptions,  simplifications,  values  of  input  parameters,  and  the 
selection  of  output  measures  to  be  estimated.  [Ref.  5] 

This  is  one  reason  MCCAAM  can  be  so  effective  for  studying  the  large, 
complex  communications  process.  If  a  particular  analyst  or  decision  maker 
does  not  think  the  input  parameters  are  accurate  for  a  given 
simulation /analysis  scenario,  sensitivity  analysis  can  easily  give  insight  into 
the  effects  of  changing  assumptions  or  values  of  those  input  parameters.  An 
example  of  the  possibilities  afforded  in  this  area  with  MCCAAM  is  presented 
in  the  next  chapter. 
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V.  ANALYSIS  EXAMPLE 

A.  GENERAL 

Because  simulation  involves  statistical  sampling  from  waiting  time 
distributions,  repetition  of  a  simulation  under  a  fixed  set  of  factor 
conditions  produces  variable  results.  Thus  we  have  a  situation  in  which 
(1)  we  have  a  large  number  of  variables  to  consider  and  (2)  the  variation 
cannot  be  ignored.  This  is  exactly  the  situation  for  which  experimental 
designs  were  invented.  [Ref.  30] 

Even  a  well  documented  model  may  generate  non-credible  results 
without  an  appropriate  experimental  design  which  can  establish  the 
statistical  validity  of  the  model  under  varying  environments.  [Ref.  18] 

Since  we  want  to  investigate  how  the  various  parameters  and  particular 
structural  assumptions  of  MCCAAM  affect  its  measures  of  performance,  we 
need  a  structured  experimental  environment  to  conduct  intelligent  analyses. 

In  the  simulation  context,  experimental  design  provides  a  means  to 
decide  beforehand  which  system  parameters  to  use  or  change  so  the  desired 
information  can  be  obtained.  As  we  learn  more  about  the  behavior  of  a  model 
(in  particular,  which  factors  really  matter  and  how  they  appear  to  be  affecting 
the  response),  we  may  want  to  move  on  and  become  more  specific  with  our 
goals.  [Ref.  30] 

To  begin  our  experimental  analysis,  it  is  necessary  to  define  the  type  of 
simulation  we  are  going  to  run. 

B.  TERMINATING  OR  STEADY-STATE  ? 

'The  two  types  of  simulations  with  regard  to  analysis  of  output  data  are 
terminating  and  steady-state  simulations."  [Ref.  34]  We  begin  this  section  by 
defining  what  we  mean  by  these  two  terms. 
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•  "A  terminating  simulation  is  one  for  which  the  desired  measures  of 
system  performance  are  defined  relative  to  the  interval  of  simulated 
time  [0,  T],  where  T  is  the  instant  in  the  simulation  when  some 
specified  event,  E,  occurs.  (Note  that  T  may  be  a  random  variable.) 
Since  measures  of  performance  for  terminating  simulations  explicitly 
depend  on  the  state  of  the  simulated  system  at  time  0,  care  must  be 
taken  in  choosing  initial  conditions."  [Ref.  34] 

•  "A  steady-state  simulation  is  one  for  which  the  measures  of 
performance  are  defined  as  limits  as  the  length  of  the  simulation  goes 
to  infinity.  Since  there  is  no  natural  event  E  to  terminate  the 
simulation,  the  length  of  one  simulation  is  made  large  enough  to  get 
"good"  estimates  of  the  quantities  of  interest.  Steady-state  does  not 
mean  that  the  actual  delays  in  a  single  realization  (or  run)  of  the 
simulation  become  constant  after  some  point  in  time,  but  that  the 
distribution  of  the  delays  becomes  invariant"  [Ref.  34] 

From  the  definitions  above,  it  is  clear  that  for  some  systems  either  type  of 
simulation  might  be  appropriate,  depending  on  what  the  analyst  wants  to 
learn  about  the  system.  For  example,  in  a  complex  communications  model 
like  MCCAAM,  a  steady-state  simulation  might  be  designed  to  estimate  the 
penalty  accrual  rate  after  the  user-defined  MAGTF  has  been  operating  long 
enough  for  the  exercise /battle  to  have  progressed  through  all  possible  phases 
of  operation.  Another  application  could  be  to  estimate  the  steady-state 
expected  average  message  completion  time  for  an  architecture  if  the  MAGTF 
was  to  operate  at  a  high  traffic  intensity  for  an  indefinite  period  of  time. 

To  use  MCCAAM  as  a  terminating  simulation  tool,  consider  the  analyst 
who  wants  to  look  at  starting  a  network  cold  and  then  study  the  measures  of 
effectiveness  after  one  twenty-four  hour  period  of  normal  activity.  The 
initial  conditions  in  this  case,  empty  and  idle,  would  provide  a  realistic 
assessment  of  the  normal  beginning  of  an  operation  when  all  concerned 
units  are  just  establishing  communications. 
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Another  terminating  application  could  be  the  analysis  of  a  short  war 
where  the  traffic  intensity  was  a  non-homogeneous  Poisson  process.  Creating 
cycles  of  high  intensity  traffic  in  the  early  morning  and  late  evening  hours  for 
each  twenty-four  hour  period  would  provide  a  realistic  traffic  environment, 
where  most  intense  conflicts  might  take  place  outside  of  the  middle  of  the 
day.  The  end  of  the  three  days  would  terminate  the  simulation  and  the 
resulting  MCCAAM  penalty  statistics  and  other  measures  of  effectiveness 
could  provide  comparative  insight  when  examined  against  a  competing 
architecture  pushed  through  the  same  simulation  environment.  Scripted 
message  traffic  from  an  actual  exercise  would  provide  a  great  example  of  this 
type  of  terminating  analysis. 

A  major  consideration  in  how  we  approached  our  analysis  was  the  need 
to  eliminate  as  much  unwanted  variability  as  possible  in  our  model. 
Variability  that  just  adds  fog  to  a  model,  without  affecting  any  measures  of 
effectiveness  in  a  significant  way,  makes  any  analysis  task  more  difficult.  A 
short  run,  terminating  simulation  would  have  added  more  traffic  variability 
that  would  have  detracted  from  our  comparative  analysis.  Since  we  were  not 
given  a  specific  scenario  to  model  and  the  goal  of  the  study  focused  on  the 
long-term  effects  of  architecture  differences,  we  made  the  decision  to  look  at 
our  system  measures  from  a  steady-state  perspective.  This  decision  was 
embraced  by  our  Marine  Corps  sponsors. 

C    MODEL  SPECIFICS 
1.     Simulation  Time 

Since  a  steady-state  simulation  approach  was  taken  for  this   example 
analysis,  we  are  interested  in  examining  the  expected  average  MOE  values 
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after  one  simulation  run  of  sufficient  duration  to  ensure  good  estimates.  The 
length  of  sufficient  duration  that  is  needed  is  dependent  on  how  long  the 
simulated  system  takes  to  reach  steady-state  conditions.  The  time  our 
communication  system  takes  to  reach  steady-state  conditions  is  calculated  by 
means  of  the  penalty  output  analysis  described  by  Bailey  in  [Ref.  25].  To 
summarize  this  method,  we  examine  sequential  time  samples  of  the  penalty 
accumulation  rate  at  fixed  intervals  (starting  from  the  end  of  the  simulation, 
when  the  system  is  in  steady-state)  and  compute  F  statistics  to  determine 
when  the  distribution  changes  a  statistically  significant  amount.  Since  the 
time  samples  are  taken  from  the  end  of  the  simulation  run,  the  point  at 
which  the  F  statistic  allows  us  to  reject  the  null  hypothesis,  (the  penalty  rate 
samples  are  from  the  same  distribution),  we  can  mark  that  time  as  the  end  of 
the  initial  transient  conditions  and  the  beginning  of  steady-state.  This 
method  is  further  detailed  in  [40]. 

Using  the  above  approach,  we  found  that  for  the  level  of  traffic 
intensity  we  were  modelling  (see  Appendix  I  for  Traffic  Data)  the  simulation 
entered  its  steady-state  range  very  quickly  (approximately  2,000  minutes). 
Since  we  knew  we  would  need  to  drop  the  output  from  the  first  2,000 
minutes  and  still  want  a  good  sample  of  steady-state  output,  we  conducted 
our  production  runs  for  a  10,000  minute  duration  (approximately  7  days). 

Because  we  are  unable  to  start  the  simulation  off  at  time  0  in  a  state 
which  is  representative  of  the  steady-state  behavior  of  the  architecture,  the 
output  data  at  the  beginning  of  the  simulation  are  not  good  estimates  of  the 
steady-state  MOE  responses  we  are  interested  in.  Since  the  penalty  rate  for 
each  architecture  was  the  only  MOE  to  be  statistically  analyzed  with  a  steady- 
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state  approach,  the  initial  transient  problem  was  dealt  with  by  dropping  the 
first  2000  minutes  worth  of  penalty  rate  output  data.  [Ref.  34:p.  307] 

2.  Units  and  Nets 

Figure  21  on  the  following  page  shows  the  sub-network  of  the  MEB 
communications  architecture  that  we  are  using  for  this  analysis  example.  As 
the  figure  details,  we  are  simulating  only  the  major  Fire  Support  nets  of  the 
Ground  Combat  Element  of  the  MEB.  The  sub-network  involves  the  Brigade 
Operations  Center,  the  Regimental  Operations  Center,  the  three  infantry 
battalions  (each  with  three  companies  and  one  81  mm  Mortar  Platoon),  and 
the  Artillery  Battalion  with  its  three  Artillery  Batteries.  The  fourth  artillery 
battery,  N5/11,  is  a  self-propelled  artillery  battery  that  has  been  attached  to  the 
Regiment  to  help  support  the  mechanized  battalion  in  its  maneuver 
operations.  There  are  a  total  of  22  units  or  command  and  control  facilities 
(C2FACs)  using  a  total  of  19  different  communications  nets  with  102  radios. 
Each  link  between  the  units  in  Figure  21  actually  represents  all  the  different 
nets  that  currently  connect  two  given  units.  For  example,  the  line  connecting 
the  3d  Marine  Regiment  to  the  1/12  Arty  Battalion  actually  represents 
connectivity  between  these  two  units  on  an  Intelligence  Net,  a  Fire  Support 
Control  Net,  a  Conduct  of  Fire  Net,  and  a  Regimental  Tactical  Net. 

3.  Radios  and  Jammers 

For  the  architecture  illustrated  on  the  next  page,  the  22  units  own  a 
total  of  102  radios  which  can  be  designated  as  PRC-77,  SINCGARS,  or  HF  types 
in  the  data  base  manipulation  program.  Providing  the  essential  threat  stress, 
we  model  two  jammers  which  are  located  within  range  of  all  the  units 
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modelled  in  this  sub-network.    All  the  jammer  specific  data  for  our  analysis 
can  be  found  in  Appendix  E. 
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Figure  21.  1st  MEB  Fire  Support  Architecture 
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4.     Analysis  Set-Up 

As  an  example  of  how  MCCAAM  can  be  used  by  Marine  Corps 
analysts,  the  simulation  experiment  in  this  thesis  compares  four  different 
SINCGARS  allocation  schemes  for  the  Fire  Support  nets  of  a  standard  Marine 
Expeditionary  Brigade  (MEB)  architecture.  The  object  of  this  experiment  is  to 
determine  whether  there  is  any  difference  between  the  communication 
abilities  of  this  portion  of  the  MEB  for  the  different  allocations,  to  estimate 
the  differences,  and  to  assess  the  precision  of  the  estimates.     A  short 

description  of  each  of  the  allocation  schemes  follows: 

•  Allocation  Scheme  1  is  the  standard  benchmark  for  the  analysis.  It 
represents  the  way  the  Marine  Corps  MEBs  currently  communicate. 
All  the  MEB  units  are  using  only  the  fixed-frequency  VRC-12  and  PRC- 
77  family  of  radios. 

•  Allocation  Scheme  2  represents  the  philosophy  that  the  higher  level 
nets  are  carrying  more  important  information  and  therefore  need  the 
protection  that  SINCGARS  provides.  Therefore,  under  this  scheme, 
SINCGARS  are  issued  to  the  high  level  nets  first  and  then  down  the 
architecture  until  depleted. 

•  Allocation  Scheme  3  is  for  those  who  would  propose  that  the  new, 
highly  reliable  anti-jam  radios  need  to  go  to  the  units  who  operate  in 
the  field  the  most.  Those  tactical  units  which,  in  combat,  will  be 
actively  engaged  with  the  enemy  the  greatest  amount  of  time.  So,  for  a 
given  number  of  SINCGARS,  the  subscribers  on  the  nets  at  the  lowest 
level  are  issued  SINCGARS  until  the  number  of  available  radios  is 
depleted. 

•  Allocation  Scheme  4  assigns  the  available  SINCGARS  radios  to  the 
nets  that  are  used  the  most  with  the  current  traffic  workload.  This 
allocation  obviously  does  not  protect  the  most  "important"  traffic,  but 
it  provides  yet  another  example  for  comparison,  and  is  a  potential 
consideration  for  decision  makers. 

The  flow  for  each  allocation  scheme  in  Figure  22  below  illustrates  a 

simulation  run  in  MCCAAM  with  the  same  workload  sample  path  and 

jammer  interaction.    The  output  for  each  iteration  or  run  are  the  statistics 
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used  for  calculating  the  seven  communication  MOEs  and  the  accrued  penalty, 
P.  For  each  allocation  scheme,  the  seven  MOE  values  are  calculated  or  taken 
straight  from  the  output  files  as  described  in  Chapter  IV.  Next,  the  utilities  of 
each  of  the  MOE  values  is  calculated  with  user-defined  utility  curves.  Using 
weights  obtained  from  a  pair-wise  comparison  of  all  the  MOEs  as  described  in 
Chapter  IV,  we  then  aggregate  the  seven  MOEs  to  obtain,  E,  an  aggregate 
measure  of  that  architecture's  communications  performance. 


AS1 
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AS3 


AS4 


Baseline  Allocate  Allocate  Allocate 

All  PRC-77  FEBABack  Top  Down         Busiest  Nets 


(  MCCAAM^)         (MCCAAM    )      (  MCCAAM^)  ( MCCAAM    ) 


©  ©    ©  ©   ©©  ©  © 


Figure  22.  Experimental  Flow 
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We  would  like  to  see  that  both  aggregate  measures  of  effectiveness 
choose  the  same  architecture  as  "the  best",  but  the  aggregation  of  the  seven 
individual  measures  considers  effects  of  more  factors  than  does  the  overall 
penalty  MOE  and  might  yield  different  results  in  certain  circumstances. 

Once  we  have  obtained  all  the  measures  of  effectiveness  for  each  of 
the  four  allocation  schemes,  we  are  interested  in  choosing  the  architecture 
that  gives  us  the  best  measures  of  effectiveness  in  the  most  areas. 

The  next  chapter  provides  model  results  and  an  example  of  how  an 
analyst  can  provide  a  decision  maker  with  a  quantifiable  comparison  of  the 
architecture  under  study. 
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VI.  OUTPUT  ANALYSIS 

Four  example  architectures  were  developed  to  demonstrate  the  utility  of 
MCCAAM  as  both  an  analytic  and  planning  tool.  The  baseline,  model  as 
described  in  the  previous  chapter,  provides  a  point  of  reference  for 
comparison  of  experimental  results.  The  three  additional  scenarios 
demonstrate  the  use  of  MCCAAM  as  a  planning  tool  and  allow  the  user  to 
compare  results  of  alternative  tactical  plans  with  those  of  the  baseline  model. 

A.    MODEL  VERIFICATION 

Before  describing  the  steps  taken  in  verifying  MCCAAM,  we  begin  by 
giving  some  simple  definitions  of  verification,  validation,  and  output 
analysis  to  avoid  any  confusion  over  what  is  being  referred  to.  "Verification  is 
determining  whether  a  simulation  model  performs  as  intended,  i.e.  properly 
debugging  the  program."  [Ref.  34]  Although  simple  in  concept,  this  was  very 
difficult  for  a  large-scale  simulation  model  like  MCCAAM.  "Validation  is 
determining  whether  a  simulation  model  (as  opposed  to  the  computer 
program)  is  an  accurate  representation  of  the  real-world  system  under  study. 
This  is  to  be  contrasted  with  output  analysis  which  is  concerned  with 
determining  a  simulation  model's  (not  necessarily  the  system's)  true 
parameters  or  characteristics." [Ref.  34:p.  333] 

Our  model  verification  goal  was  to  confirm  that  MCCAAM  was  producing 
the  numbers  that  we  desired  when  we  implemented  our  model  logic.  This 
was  accomplished  in  large  part  by  five  techniques  [Ref.  34]  briefly  described 
below  : 
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Technique  1:  In  developing  MCCAAM,  we  wrote  and  debugged  the 
entire  program  in  modules.  The  modular  structure  of  MODSIM  II 
made  this  very  easy  and  natural  and  greatly  assisted  in  testing 
subprogram  structures.  As  the  program  coding  progressed,  additional 
levels  of  detail  were  successively  added  until  the  model  satisfactorily 
represented  our  system  of  interest. 

Technique  2:  Realizing  it  is  advisable  to  have  more  than  one  person 
"proof"  the  computer  program  when  large  simulation  models  are 
being  developed,  we  implemented  this  formally  with  periodic 
structured  walk-throughs.  These  walk-throughs  allowed  the  three 
members  of  the  modelling  team  to  work  through  modules  step-by-step 
to  reach  mutual  agreement  on  logic  and  implementation  style. 

Technique  3:  One  of  the  more  powerful  verification  techniques  that 
can  be  used  to  debug  a  discrete-event  simulation  model  is  a  trace.  Once 
again,  MODSIM  made  this  very  easy  with  its  built-in  trace  stream 
objects.  Appendix  H  shows  one  page  of  our  c31og.out  file  which 
contains  examples  of  statements  that  were  written  to  the  file 
throughout  the  flow  of  the  program  to  ensure  the  system  was  behaving 
the  way  we  intended  it  to.  This  trace  stream  was  very  effective  in 
revealing  areas  of  faulty  code  or  problem  areas.  Through  appropriately 
located  comments,  we  could  pin-point  the  models  activities  in  any 
given  area  and  time  of  interest. 

Technique  4:  By  running  MCCAAM  under  a  set  of  simplifying 
assumptions  (manifest  by  changing  input  parameters)  for  which  the 
model's  true  characteristics  were  known  (or  easily  calculated),  we  were 
able  to  assure  ourselves  that  from  the  simple  level  on  up,  the  radios, 
nets,  and  messages  were  all  behaving  as  intended  and  expected. 

Technique  5:  Not  always  the  easiest  to  incorporate,  technique  five 
involves  displaying  simulation  output  on  the  terminal  screen  as  the 
simulation  actually  progresses.  Though  not  necessarily  helpful  with 
all  types  of  simulations,  this  technique  was  employed  in  MCCAAM 
through  the  graphical  portrayal  of  the  accumulating  penalty  for  the 
architecture  under  study.  Through  this  window,  which  is  active  while 
the  simulation  program  is  running,  we  see  the  the  passage  of  time  and 
the  architecture's  accumulating  penalty.  Graphical  portrayal  of  any  of 
MCCAAM's  measures  of  effectiveness  can  be  implemented  to  provide 
the  analyst  a  real-time  picture  of  the  system's  performance. 
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B.    RESULTS 

Once  the  verification  steps  discussed  above  were  completed  with  our  final 
version  of  MCCAAM,  we  were  able  to  make  production  runs  for  analysis 
purposes.  The  paragraphs  below  list  the  quantifiable  measures  of 
effectiveness  we  obtained  through  MCCAAM.  The  measures  determined 
through  the  subjective  scoring  (not  obtained  through  MCCAAM)  are  also 
presented.  The  following  list  of  abbreviation  definitions  is  provided  to 
facilitate  table  interpretation: 


W 

#Mess 
T 
GOS 

PJ 
R 

IP 

NC 

NM 

E 

P 

#Bosts 

P* 

PRate 


Average  message  wait  time  (minutes) 
Number  of  messages  completed  in  simulation  time. 
Timeliness  measure  =  l/(W/#Mess) 
Grade  of  Service  =  #Messages  Comp/#Messages  Art 
Protection  from  Jamming  =  GOSj/GOS 
Radio  Reliability  =  Number  of  radio  failures3 
Information  Protection  (calculated  from  criterion  scale) 
Network  Construction  (calculated  from  criterion  scale) 
Network  Maintenance  (calculated  from  criterion  scale) 
Sum  of  weighted  utilities  of  MOEs 
Overall  penalty  accumulated  by  given  architecture 
Number  of  BOSTS  completed  in  simulation  time. 
Scaled  Penalty  MOE  =  P/#Bosts 
Average  Penalty  Rate  for  entire  simulation  run. 


The  respective  weights  and  utilities  below  are  examples  of  values  that 
were  obtained  for  each  of  our  seven  measures  of  effectiveness  as  described  in 
Chapter  IV.  The  weights  came  from  the  paired  comparisons  of  all  MOEs 
using  Expert  Choice  and  the  utility  curves  for  each  of  the  MOEs  are  just  some 


3  The  radio  failure  numbers  in  Table  4  are  intentionally  very  large.  The 
MTBF  values  we  used  were  much  smaller  than  currently  known  values  in 
order  to  see  effects  of  high  radio  failure.  Additionally,  the  statistic  reflects  all 
the  radios  in  the  MEB  whether  they  were  used  or  not.  Since  it  is  simply  a 
relative  term  between  allocation  schemes,  the  magnitude  is  not  important. 
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of  many  that  could  be  employed.  The  specific  utility  values  listed  were 
obtained  by  substituting  Allocation  Scheme  1  MOE  values  into  the  respective 
utility  functions. 


•      Weight  (GOS) 

=  .299 

►    Utility  (GOS)  =  GOS  A  2 

=  0.871 

•      Weight  (PJ) 

=  .191 

►    Utility  (PJ)     =PJA2 

=  0.912 

•      Weight  (T) 

=  .176 

►    Utility(T)       =  2*HN 

=  0.334 

•      Weight  (R) 

=  .141 

►    Utility(R)       =  R/1000 

=  0.173 

•      Weight  (NM) 

=  .084 

►    Utility  (NM)=  NM/1000 

=  0.395 

•      Weight  (IP) 

=  .064 

►    Utility  (IP)     =  IP/1000 

=  0.395 

•      Weight  (NC) 

=  .045 

►    Utility  (NC)  =NC/1000 

=  0.395 

The  aggregate  measure  E  is  calculated  as  the  weighted  sum  of  utilities  as 
described  in  Chapter  IV: 

E  =  Xwi*Ui 

E  =  .299*U(GOS)  +  .191*U(PJ)  +  .176*U(T)  +  .141*U(R) 

+  .084*U(NM)   +   .064*U(IP)  +  .045*U(NC) 

E  =   0.5361 

Table  4  summarizes  all  the  individual  and  collective  measures  for  the 
four  allocation  schemes.  Our  experimental  results  show  that  Allocation 
Scheme  3  (FEBA  back)  produces  the  overall  best  communications  architecture 
with  respect  to  the  overall  accumulated  penalty.  Allocation  Scheme  4  appears 
to  be  the  best  architecture  with  respect  to  most  of  the  individual  MOEs  and 
the  aggregate  MOE,  E. 

An  analyst  could  now  use  these  results  to  brief  a  decision  maker  with 
quantifiable  results.      One  question  remains:   Are  these  differences  in 
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architectures  statistically  significant?   The  following  sections  discuss  how  we 
can  formally  look  at  the  differences  in  some  of  the  MOEs  obtained. 

TABLE  4.  MOE  RESULTS 


MOE 

AS1 

AS2 

AS  3 

AS4 

BEST 

W 

35.91 

44.64 

38.24 

38.88 

AS1 

#Mess 

5414 

6387 

6141 

6453 

AS4 

T 

150.83 

143.20 

160.59 

165.98 

AS4 

GOS 

93.36 

96.83 

95.89 

97.83 

AS4 

PJ 

0.955 

0.980 

0.975 

0.976 

AS2 

R 

1733 

1372 

1399 

1425 

AS2 

IP 

5 

6.97 

6.97 

7.03 

AS4 

NC 

5 

4.01 

4.01 

3.99 

AS1 

NM 

5 

4.51 

4.51 

4.49 

AS1 

E 

.5361 

.5569 

.5595 

.5669 

AS4 

P 

50331 

51,517 

48,530 

53,006 

AS3 

#  Bosts 

203 

231 

237 

248 

AS4 

P* 

247.94 

223.02 

204.78 

213.73 

AS3 

PRate 

4.67 

4.92 

4.71 

5.24 

AS1 

C    SELECTION  PROCEDURES 

The  different  MOEs  provided  in  any  MCCAAM  run  give  any  analyst  or 
decision  maker  the  ability  to  select  a  best  architecture  in  one  of  any  number  of 
different  areas.  For  example,  if  an  analyst  was  only  interested  in  how  many 
BOSTS   an  architecture  could  process  in  a  heavy  jamming  environment,  then 
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he  could  make  his  selection  based  strictly  on  the  Protection  from  Jamming 
(PJ)  MOE. 

If  there  is  no  clear  difference  in  the  performance  of  competing 
architectures  when  examining  all  the  tabulated  measures  of  effectiveness, 
then  there  is  no  reason  to  pursue  further  analysis.  On  the  other  hand,  if  there 
seems  to  be  a  difference  in  the  performance  of  competing  architectures,  we 
want  to  provide  a  decision  maker  with  some  sense  of  how  much 
performance  difference  exists. 

The  following  sections  discuss  statistical  approaches  to  help  assess  those 
performance  differences. 

D.    ANALYSIS  OF  DESIGN  AND  MOES 

A  natural  first  step  is  to  compare  all  the  architectures  or  systems  to  a 
standard  or  reference  point  to  discern  the  magnitude  of  performance 
differences.  Beyond  comparison  to  a  reference  point,  one  of  the  simplest  and 
most  intuitive  approaches  when  comparing  two  systems  is  to  examine  the 
difference  in  the  average  values  of  a  specific  measure  of  effectiveness.  The 
most  efficient  way  to  look  at  differences  is  through  a  confidence  interval 
approach,  so  this  technique  is  presented  below. 

1.     Confidence  Intervals  for  Steady-State  Simulations 

For  our  analysis  example,  we  are  interested  in  the  penalty  rate  output 
for  a  single  steady-state  simulation  run.    If  we  let  the  variables  pi,  p2,   •  •,  pj 

represent  this  output  process  and  pi  represent  the  architecture's  penalty  rate 
at  time  i  in  the  simulation  run,  then  we  define  the  steady-state  average 
response  p*  of  pi  (when  it  exists)  by: 
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p*=  lim  — — — w.p.  1 
m-»oo      m 

Of  the  two  general  approaches  given  in  most  simulation  literature  for 
constructing  a  confidence  interval  for  p*,  we  chose  the  fixed-sample-size 
approach.  Within  the  fixed-sample-size  approach,  there  are  five  or  more 
techniques  available.  We  chose  the  batch  means  technique  which  partitions 
the  output  data  p\,  p2,   •  •,  pj  into  approximately  IID  observations  to  which 

classical  statistical  analyses  can  be  applied  to  construct  a  confidence  interval. 
[Ref.  30] 

For  the  batch  means  technique,  we  make  a  simulation  run  of  length 
m  and  then  divide  the  resulting  observations  (whether  they  be  penalty  rate, 
grade  of  service,  or  number  of  BOSTS)   into  n  batches  of  length  /.  (Assume 
that  m  =  nl)  Thus,  batch  1  contains  observations  p\,  p2, ...,  pi  etc.  If  we  let 

Pj(l)  be  the  batch  mean  of  the  /  observations  in  the  jth  batch  and 

be  the  grand  sample  mean,  then  we  can  use  P(n,l)  as  our  point  estimator  for 
P*.    Thus  the  P.(/)  's  play  the  same  role  for  batch  means  as  the  individual 

observations  do  for  the  terminating  case  confidence  interval. 

If  we  choose  the  batch  size  /  large  enough,  it  can  be  shown  that  the 
*jW  's  will  be  approximately  uncorrelated.  Additionally,  if  /  is  chosen  large 
enough,  there  are  central  limit  theorems  for  correlated  stochastic  processes 
that  allow  us  to  assume  the  P.(/)  's  to  be  approximately  normally  distributed. 
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Ten  differences  between  averages  from  comparable  non-overlapping 
sequences  of  observations  will  be  nearly  normally  distributed  because  of 
the  central  limit  effect.  Furthermore,  even  though  successive  individual 
batch  yields  are  almost  certainly  statistically  dependent,  the  differences 
between  averages  will  be  distributed  approximately  independently.  [Ref. 
30:  p.  51] 

Therefore,  if  the  batch  size  /  is  large  enough,  it  follows  that  it  is  not 

unreasonable  to  treat  the  Py(/)  's  as  if  they  were  IID  normal  random  variables 

with  mean  u.   and  to  construct  an  approximate  100(l-a)  percent  confidence 
interval  for  |i  from 

P(n,l)  ±  t^MiVs&nyn 
2 

where  the  sample  variance  of  the  mean  is 

n 

XfoO)-P(rU)]2 

s2(n)  =  tL. 


n-1 

Using  the  approach  above,  we  ran  MCCAAM  for  10,000  minutes, 
deleted  the  first  2000  minutes  worth  of  penalty  output,  and  then  collected  31 
batches  of  size  5  by  sampling  from  the  penalty  process  every  50  minutes.  For 
each  of  the  four  allocation  schemes,  the  global  penalty  rate  batch  means, 
standard  deviations  of  the  means,  and  associated  95%  confidence  intervals 
are  listed  below: 


AS1 

AS2 

AS3 

AS4 

Batch  Mean* 

4.67 

4.92 

4.71 

5.24 

Stand.  Dev. 

0.246 

0.255 

0.273 

0.302 

Conf.  Interval 

(4.17,5.17) 

(4.40, 5.44) 

(4.15, 5.26) 

(4.62, 5.86) 
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2.     Multiple  Comparisons  with  a  Standard 

Using  the  standard  treatment  (AS1  :  No  SINCGARS  in  architecture) 
as  a  benchmark  against  which  to  compare  the  specific  allocation  schemes,  the 
question  to  be  answered  is  whether  or  not  any  of  the  treatments  may  be 
considered  to  be  different  from  the  mean  of  the  standard. 

With  k=4  allocation  schemes,  the  statistic  of  interest  is  the  k-l=  3 


differences  ASi-  ASi  where  ASi  is  the  observed  average  response  for  the 
baseline  architecture  with  no  SINCGARS.  The  1-a  confidence  intervals  for 
all  3  differences  from  the  standard  are  calculated  from  Dunnett's  Procedure 
[Ref.  30:p.  205]  as  given  below: 


±t„v,a/2  S  VnT+nT 


where  ^,v,o/2  values  are  found  in  Dunnett  (1964).  S  is  the  pooled  sample 
standard  deviation,  obtained  from  the  four  individual  standard  deviations 
and  v  is  the  degrees  of  freedom  of  the  estimate  s^- 

Thus  for  our  example  with  k  =  4  allocation  schemes  and  31  batch 
mean  observations  for  each  allocation  scheme,  we  have  v  =  120  and  95% 
confidence  limits 


±2.51*1.50yX7X  = 


0.96 


Therefore  any  observed  difference  from  the  standard  greater  than  0.96  in 
absolute  value  can  be  considered  statistically  significant  at  the  a  =  0.5  level. 
The  3  differences  that  follow  show  that  none  of  the  average  penalty  rates  is 
statistically  significant  from  the  standard  at  the  0.05  level: 
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AS1 

AS2 

AS3 

AS4 

Avg.  P  Rate 

4.67 

4.92 

4.71 

5.24 

Difference 

* 

0.25 

0.04 

0.57 

Though  it  is  good  practice  to  allot  more  observations  to  the  control 
treatment  than  to  each  of  the  other  treatments,  we  have  31  batch  means  for 
all  four  of  the  architectures  of  interest. 
3.     Comparison  of  Two  Averages 

The  approach  demonstrated  here  for  determining  if  there  is  a 
significant  difference  between  any  two  MOEs  can  be  applied  to  most  any  of  the 
statistics  collected  in  MCCAAM  to  provide  further  insight  into  architecture 
differences. 

In  our  example,  we  are  interested  in  providing  a  decision  maker  with 
some  idea  as  to  the  magnitude  of  the  performance  difference  between  the  top 
two  communications  architectures.  We  accomplish  this  by  constructing  a 
confidence  interval  for  the  difference  in  the  mean  values  of  the  two  MOEs  of 
interest.  This  approach  provides  more  information  than  if  we  were  to  simply 
conduct  a  hypothesis  test  to  see  whether  the  observed  differences  could  be 
distinguished  from  zero. 

For  this  example,  we  use  the  thirty-one  penalty  rate  batch  means 
discussed  above  as  our  sample  of  IID  observations  from  AS3  and  AS4.  For 
example,  for  allocation  scheme  four,  we  will  denote  the  individual  batch 
means  as  X4i,  X42,  X43,  ...,  X431.  We  are  interested  in  H  =  E(XIj),  the  global 
penalty  rate  batch  mean  for  the  entire  simulation  run  for  each  of  the  two 
allocation  schemes.  We  want  to  construct  a  confidence  interval  for  D  = 
H(AS4)  -  |i(AS3).     By  pairing  each  of  the  31  batch  means  from  the  two 
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allocation  schemes,  we  define  Zj  =  X4j  -  X3j  for  j  =  1,  2,  ...,  31  and  we  have  IID 
random  variables,  Zj,  where  E(Zj)  =  D.  So,  we  let 


£  Zj  _  t  fr  Z(n)3 


Z(n>  =  ^     and  LVVJ"        n(n-l) 

and  we  form  the  approximate  100(1 -a)  percent  confidence  interval 

Z(n)  ±  tn.i,  mx/2  VcT2[z(n)] 

If  the  Zj's  are  normally  distributed,  this  confidence  interval  covers  D  with 
probability  1-a;  otherwise,  we  rely  on  the  central  limit  theorem  which 
implies  that  this  coverage  probability  is  near  1-a  for  large  n.  An  important 
point  here  is  that  we  did  not  have  to  assume  that  the  allocation  batch  means 
are  independent;  nor  did  we  have  to  assume  that  the  variances  were  equal. 
The  following  paired-t  confidence  interval  is  obtained  for  our  example: 

Z(n)  =  0.536  ^Z(n)]  =  51.25/31(30)  =  0.055 

Va^Zdi)]  =  o.235 

These  values  give  us  a  95%  confidence  interval  of 

(0.0567, 1.015) 

for  D  =  n(AS4)  -  n.(AS3).  So,  with  approximately  95%  confidence,  we  can  say 
that  u(AS3)  differs  from  (i(AS4),  and  it  appears  that  AS3  is  better  with  respect 
to  penalty  accrual  rate,  since  it  leads  to  a  lower  average  penalty  rate. 
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E     VARIANCE  REDUCTION 

The  first  (and  probably  most  useful  and  popular)  variance  reduction 
technique  that  we  considered,  common  random  numbers  (CRN),  applies 
when  one  is  comparing  two  or  more  alternative  system  designs  —  precisely 
the  situation  in  this  experiment. 

The  basic  idea  with  this  technique  is  that  we  would  compare  the 
alternative  systems  "under  similar  experimental  conditions"  so  that  we  can 
be  more  confident  that  any  observed  differences  in  performance  are  due  to 
the  differences  in  the  system  designs  rather  than  to  fluctuations  of  the 
"experimental  conditions."  In  simulations,  the  experimental  conditions  are 
the  generated  random  variables  that  are  used  to  drive  the  models  through 
simulated  time. 

The  name  of  this  technique  stems  from  the  possibility  in  some  situations 
of  using  the  same  stream  of  basic  U(0,1)  random  variables  to  drive  each  of  the 
alternative  models  through  time.  In  the  terminology  of  classical  experimental 
design,  CRN  is  a  form  of  blocking.  This  was  carried  out  in  MCCAAM  by 
ensuring  each  of  the  radio  allocation  schemes  was  exposed  to  the  exact  same 
traffic  workload.  No  formal  analysis  is  presented  to  show  the  effects  of 
simulating  the  different  architectures  with  different  variable  traffic 
workloads. 

F.     MODEL  VALIDATION 

Though  not  fully  accomplished  with  MCCAAM,  the  three-step  approach 
to  validation    presented  here  is  an  approved  approach  [Ref.  34]  which  has 
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been  carried  out  to  some  degree.    The  remaining  validation  steps  await  time 
and  future  testing. 

1.  Develop  a  Model  with  High  Face  Validity 

As  an  initial  objective,  we  determined  to  develop  a  model  which,  on 

the   surface,   seemed   reasonable   to   Marines   knowledgeable   about   the 

communication  system  being  modeled.    We  tried  to  make  use  of  all  existing 

information,  which    included  the  following: 
Intuition 

General  Knowledge 
Observations  of  the  system 
Existing  theory 
Conversations  with  experts 

2.  Test  the  Assumptions  of  the  Model  Empirically 

The  goal  of  this  step  is  to  quantitatively  test  the  assumptions  made 
during  the  initial  stages  of  model  development.  One  of  the  most  useful  tools 
during  the  second  validation  step  is  sensitivity  analysis.  This  technique  was 
used  to  determine  how  much  MCCAAM  output  varied  with  small  changes 
in  specific  parameters.  Another  important  use  of  sensitivity  analysis  is  to 
determine  the  level  of  detail  at  which  a  particular  sub-system  is  to  be 
modelled. 

3.  Determine  How  Representative  the  Simulation  Output  Are 

Probably  the  most  definitive  test  of  the  validity  of  a  simulation  model  is 
to  establish  that  the  model  output  data  closely  resemble  the  output  data 
that  would  be  expected  from  the  actual  system.  [Ref.  34] 

If  there  was  specific  enough  communications  data  available  from  a 

MEB  field  exercise,  there  are  a  number  of  statistical  tests  available  in 

validation  literature  for  comparing  output  data  from  MCCAAM  to  the  MEB 
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exercise  data.  Since  the  output  processes  of  almost  all  real-world  systems  and 
simulations  are  non-stationary  (the  distributions  of  the  successive 
observations  change  over  time)  and  auto-correlated  (the  observations  in  the 
process  are  correlated  with  each  other)  the  comparison  would  be  difficult 
without  a  model  like  MCCAAM.  Using  the  exercise's  scripted  message  traffic 
to  drive  the  simulation,  model  output  could  be  used  for  validation  tests. 

Since  MCCAAM  is  only  an  approximation  to  the  actual 
communication  architecture,  a  null  hypothesis  that  the  system  and  model  are 
the  same  is  clearly  false.  We  believe,  along  with  Law  and  Kelton  "that  it  is 
more  useful  to  ask  whether  or  not  the  differences  between  the  system  and  the 
model  are  significant  enough  to  affect  any  conclusions  derived  from  the 
model/'  [Ref.  34] 

In  addition  to  statistical  procedures,  one  can  use  a  Turing  test  [Ref. 
34:p.  341]  to  compare  the  output  data  from  a  specific  field  exercise  to  that  of  a 
MCCAAM  simulation  of  that  exercise  scenario.  In  a  Turing  test,  Marines 
knowledgeable  about  the  exercise  and  the  communications  involved  would 
be  asked  to  examine  one  or  more  sets  of  exercise  data  and  one  or  more  sets  of 
MCCAAM  results  without  knowing  which  data  was  which.  If  these  "experts" 
can  differentiate  between  the  exercise  data  and  the  MCCAAM  data,  their 
explanation  of  how  they  were  able  to  do  it  can  be  used  to  improve  the  model. 
[Ref.  34] 

MCCAAM  output  data  could  be  compared  to  communications  data 
from  a  major  field  exercise  if  the  particular  data  needed  for  validation  was 
collected  and  made  available.  An  immediate  recommendation  is  to  establish 
a  MCCAAM  simulation  of  a  joint  Army /Marine  Corps  field  exercise  at  Fort 
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Irwin,  California  and  take  advantage  of  the  Army's  extensive  data  collection 
effort  at  their  National  Training  Center  (NTC)  to  compare  the  exercise  results 
to  the  MCCAAM  results.  This  type  of  validation  effort  would  go  a  long  way 
toward  establishing  the  benefits  of  a  communications  analysis  model  and  also 
provide  great  insight  into  other  areas  of  MCCAAM  development. 


126 


VII.  SUMMARY,  CONCLUSIONS,  RECOMMENDATIONS 

A.    MODEL  AND  ANALYSIS  SUMMARY 

In  this  study,  we  have  proposed  a  new  paradigm  for  workload  modeling 
in  military  communications  systems  which  reflects  the  dynamics  and 
dependencies  of  the  actual  system,  while  not  requiring  a  complex,  high 
resolution  combat  model.  This  workload  model  is  facilitated  by  the 
MBOT/BOST/MEO  structure  previously  described. 

We  constructed  an  object-oriented  simulation  model  of  the 
communications  system  which  exploits  the  given  Marine  Corps  message 
structure,  and  we  measured  the  performance  of  the  system  through 
traditional  communication  MOEs  and  a  penalty  accumulation  process.  As  we 
anticipated,  both  the  object-oriented  modelling  approach  and  the  MODSIM  II 
language  were  found  to  be  powerful  and  easy  to  use. 

We  have  constructed  a  reusable  tool  for  analysis  of  single-channel  voice 
communications  architectures.  By  using  the  model  in  concert  with  the 
database  manipulation  program  as  depicted  in  Figure  23,  a  communications 

analyst  is  afforded  a  rare  opportunity  to  [25]: 

•  observe  the  effects  of  doctrinal  modifications  to  routing,  net  use,  or 
directed  nets, 

•  improve  allocation  of  advanced  technology  single  channel  radios  in 
the  MAGTF, 

•  determine  the  overall  capacity  of  an  architecture  to  handle  a  mixture  of 
data  and  voice  traffic, 

•  react  to  changing  environments  involving  jamming  and  other  threats 
within  a  pristine  experimental  environment. 
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To  summarize  the  results  of  the  limited  analysis  example,  we  re-visit  the 

respective  measures  of  effectiveness  for  the  four  different  allocation  schemes 

in  Table  5  below. 

TABLES.  MOE  Summary 


AS1 

AS2 

AS3 

AS4 

"Best" 

Bosts 

203 

231 

237 

248 

AS4 

E 

.5361 

.5569 

.5595 

.5669 

AS4 

P* 

247.9 

223.0 

204.8 

213.7 

AS3 

As  discussed  in  Chapter  six,  these  measures  of  effectiveness  might  not 
have  any  significant  meaning  when  an  actual  architecture  of  type  similar  to 
the  model  is  observed  in  a  given  field  exercise.  The  strength  of  these 
measures  lies  in  their  ability  to  provide  a  means  for  comparative  analysis 
between  two  similar  systems.  Given  the  control  that  the  simulation  model 
provides  over  the  communications  environment,  we  can  assess  differences 
in  performance  between  two  competing  architectures  due  to  the  differences  in 
the  architecture  composition. 

The  results  from  the  four  different  allocation  schemes  analyzed  by 
MCCAAM  produced  distinct  measures  of  effectiveness.  The  aggregation 
approach  used  in  this  thesis  with  accompanying  utility  curves  presents  a 
MCCAAM  user  with  a  flexible,  rational  means  to  quantify  a  given 
architecture  with  a  single  measure.  The  unique  penalty  accrual  process  was 
shown  to  be  a  natural  and  effective  aggregate  measure  of  overall  system 
performance. 
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B.    CONCLUSIONS 

In  order  to  maintain  the  best  equipped  force-in-readiness,  the  Marine 
Corps  is  pursuing  new  communications  technology  at  all  operational  levels. 
To  best  implement  the  new  communications  equipment,  the  Marine  Corps 
must  be  able  to  compare  proposed  architectures  before  they  are  purchased  and 
fielded.  Specifically,  the  acquisition  of  the  new  frequency-hopping 
SINCGARS  radios  over  the  next  few  years  presents  an  allocation  concern. 

It  was  the  purpose  of  this  thesis  to  design  and  implement  a  simulation 
model  to  provide  Marine  Corps  decision  makers  and  communications 
officers  the  ability  to  quantify  the  effectiveness  of  alternate  tactical  radio 
system  configurations.  We  did  not  attempt  to  simulate  reality  but  provide 
instead  an  effective  comparative  analysis  tool.  In  all  cases  where  choices  were 
made  concerning  the  inclusion  of  certain  aspects  of  Marine  communications, 
the  question  asked  was:  Does  it  help  to  distinguish  between  different 
communications  architectures? 

Based  on  the  research  conducted  and  the  results  detailed  in  this  thesis,  it 

is  our  conclusion  that: 

•  a    comparative    analysis    tool    for    Marine    Corps    communication 
architectures  is  needed. 

•  optimal  allocation  of  new  communications  resources  is  required 

•  MCCAAM  is  a  viable  tool  to  achieve  both. 

C    RECOMMENDATIONS 

As  with  most  modelling  and  analysis  efforts,  each  problem  solved  or 
question  answered  usually  generates  many  more  to  be  considered.  There  still 
remains  quite  a  bit  of  work  that  can  be  done  to  expand  MCCAAM's  usefulness 
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to  the  Marine  Corps.    The  following  paragraphs  highlight   potential  areas  of 

future  work  or  research. 

•  MEB  Data  Base.  Our  first  recommendation  is  to  complete  the  MEB  data 
base  files  to  allow  for  full  and  accurate  analysis  of  a  MEB 
communications  architecture.  This  will  involve  extensive  work 
inputting  message  workload  data  in  the  form  of  BOSTs  and  MEOs,  but 
will  provide  an  extremely  powerful  analysis  tool. 

•  Digital  Traffic  The  current  form  of  MCCAAM  does  not  model  all  the 
different  complexities  of  digital  transmissions.  It  treats  digital  messages 
simply  as  burst  transmissions  requiring  a  reduced  time  to  transmit. 
The  effect  on  any  analysis  is  to  decrease  the  load  on  the  affected  nets 
because  of  the  reduced  transmission  time.  We  currently  have  not 
provided  for  different  protocols,  routing  procedures,  or  even 
interoperability  considerations  of  digital  message  traffic. 

Realizing  that  our  tactical  communications  should  support  short, 
"bursty,"  critical  messages  in  keeping  with  the  battlefield  environment,  a  very 
worthwhile  extension  of  the  current  study  would  be  to  examine  the 
capabilities  of  the  single  channel  radio  network  to  concurrently  serve  as  a 
voice  network  and  a  digital  data  pipeline  below  the  Infantry  Regimental 
level.  This  analysis  would  require  information  to  include  acknowledgement, 
re-transmission  and  relay  procedures,  assignment  of  digital  devices  to  units 
(C2FACs),  designation  of  specific  messages  as  digital,  band-width  capabilities 
of  the  pipelines,  and  limitations  imposed  by  the  equipment  that  is 
incorporated.  If  SINCGARS  is  not  currently  a  good  tool  for  large  data 
exchange  rates,  then  it  would  make  sense  to  allocate  the  incoming 
SINCGARS  below  regimental  level.  This  study  extension  has  already 
received  favorable  approval  from  the  Marine  Corps  study  sponsors.  [Ref.  28] 

As  another  example  of  future  MCCAAM  analysis,  consider  the  new 
tactical  data  systems  being  considered.  One  such  tactical  data  system,  the 
Portable  Data  Link  System  (PDLS),  has  been  initiated  to  meet  the  need  that 
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exists  to  provide  advance  forces  and  forward  aviation  command  elements 
with  a  compact,  rapidly  deployable  system  capable  of  exploiting  established 
tactical  data  information  links  (TADIL).  Once  modified,  MCCAAM  could  be 
used  to  measure  the    effect  on  force  communications  if  such  a  data  system 

was  widely  adopted.  [Ref.  16] 

•  Spares.  Combat  is  inefficient  because  of  the  need  for  redundancy 
(which  equates  to  survivability)  in  all  equipment — especially 
communications  equipment.  If  we  ignore  this  need  for  redundancy  in 
any  equipment  allocation  scheme,  we  are  not  being  very  realistic. 
MCCAAM  could  be  used  to  great  effect  in  studying  the  effect  of 
different  types  and  numbers  of  backup  radio  systems  at  all  force  levels. 
To  further  expand  on  the  impact  of  modelling  spares,  consider  the 
current  model.  When  a  radio  fails  in  MCCAAM,  it  is  not  available  for 
use  until  its  specified  repair  time  has  elapsed.  The  net  it  was  a 
subscriber  of  is  totally  unavailable  to  that  unit  for  that  period  of  time. 
More  realistically,  an  extra  (spare)  radio  would  be  brought  on-line, 
enter  the  net,  and  prosecute  any  waiting  messages.  In  this  manner,  the 
modelling  of  spares  will  reduce  the  penalty  associated  with  not  passing 
traffic  in  a  timely  manner. 

•  Experimental  Designs.  An  unlimited  number  of  experimental  designs 
can  now  be  pursued  with  MCCAAM  to  examine  questions  of  interest. 
A  2$  design,  such  as  the  following,  could  be  used  to  look  at  the  main 
effects  of  jamming,  radio  reliability  and  traffic  intensity. 


Test# 

#  Jammers 

MTBF 

Traff  Intense 

Penal  ty/MOEs 

1 

4 

200 

High 

2 

8 

200 

High 

3 

4 

400 

High 

4 

8 

400 

High 

5 

4 

200 

Low 

6 

8 

200 

Low 

7 

4 

400 

Low 

8 

8 

400 

Low 

Scenarios.    Different,  specific  scenarios  could  be  analyzed  to  show 
effects  of  force  size  and  threat  on  communications  effectiveness.    Data 
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obtained   from     major  field  exercises  could  be  used   to  continue 
MCCAAM's  validation  as  an  effective  analysis  tool. 

•  Movement.  Integrating  unit  movement  algorithms  would  create  a 
greater  need  for  network  construction  and  maintenance  modelling  for 
a  given  architecture.  This  would  help  differentiate  between  systems 
that  have  distinctly  different  time  costs  associated  with  net 
construction  and  maintenance. 

•  Graphics.  Integrating  more  simulation  graphics  will  assist  users  in 
tracking  communications  performance  as  the  simulation  progresses. 
For  example,  a  net  analysis  window  that  reflected  all  the  major  nets' 
traffic  volume  and  average  priority  of  traffic  could  help  shed  some 
light  on  how  individual  nets  are  used  over  time.  Further 
implementation  of  graphics  in  the  analysis  stage  of  MCCAAM  will 
also  greatly  enhance  its  ready  use. 

•  Band-width.  MCCAAM  could,  with  modifications,  be  used  to  assist  in 
determining  effects  of  changing  band-width  and  wait  time  parameters 
for  different  communications  channels. 

•  Data  problem.  During  the  entire  modelling  and  analysis  process,  we 
noted  the  recurring  need  for  data  like  that  contained  in  the  LFICS 
Scenario  and  Events  Listing  (ratio  of  different  precedence  traffic, 
average  number  of  BOSTS  for  different  types  of  units,  mean  time  to 
establish  various  types  of  nets,  etc.)  Numerous  Marine  Corps  analysis 
activities  at  the  Research  and  Development  center  such  as  Wargaming, 
C4I  Interoperability  and  Proponency,  and  the  Communications  School 
currently  rely  on  independently  gathered  data  for  respective  studies 
and  analysis  pertaining  to  communications  equipment  and  doctrine.  It 
would  be  a  very  valuable  asset  if  summaries  of  C4I  information  from 
such  exercises  as  Team  Spirit,  Combined  Arms  Exercises  (CAX's),  and 
especially  Desert  Storm  could  be  permanently  retained  in  a  central 
repository  that  was  accessible  to  all  who  would  need  it.  A  system 
similar  to  the  Marine  Corps  Lesson  Learned  System  would  greatly 
facilitate  the  use  of  such  models  as  MCCAAM,  as  the  Marine  Corps  and 
the  remainder  of  the  U.S.  military  moves  more  and  more  toward 
automated,  digital  communications. 

•  Electronic  Warfare.  Much  still  remains  to  be  accomplished  in 
enriching  the  communications  and  electronic  warfare  modules.  For 
instance,  the  limitations  and  capabilities  of  the  threat  environment 
have  not  been  modelled  in  a  detailed  manner.  The  comparative 
analysis  conducted  in  this  thesis  did  not  require  it,  but  others  might. 
Additional  technical  areas  of  the  communication  environment  could 
be  incorporated  if  a  specific  analysis  need  warranted  it.    Such  areas  of 
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directional  antennas,  antenna  height,  HF  single  side-band  radio  nets, 
and  various  power  level  effects  could  all  be  incorporated. 

Amphibious  Nets.  The  modelling  of  the  complex  communications 
involved  in  amphibious  operations  from  ship  to  shore  would  be  a  very 
involved  but  worthwhile  project. 

Hindsight  Optimization.  An  interesting  and  challenging  project  would 
be  to  develop  algorithms  that  would  allow  MCCAAM  to  assign  a  set 
amount  of  communications  assets  to  an  architecture's  units  in  a  step- 
wise fashion  that  would  optimize  the  architectures  performance  for  a 
user-specified  criteria  (timeliness,  grade  of  service,  digital  throughput, 
etc.). 

System  Reliability.  Not  specifically  addressed  in  this  thesis  but  a 
candidate  for  future  study  is  the  composite  probability  that  all  radio  sets 
are  operational  at  the  start  of  a  mission,  will  continue  to  perform 
without  failure  during  the  mission,  and  in  the  event  that  radio  sets  do 
fail  during  the  mission,  can  be  repaired  in  a  specified  time.  This  type  of 
measure  would  include  not  only  the  reliability  of  the  system,  but  the 
availability  and  maintainability   of  radios  as  well.  [Ref.lO:p.  VI-18] 
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APPENDIX  A.  MAIN  DEFINITION  MODULES 

This  appendix  contains  all  the  main  definition  modules  for  current 
version  of  MCCAAM.  These  Definition  Modules  give  a  good  overview  of 
how  the  communications  system  was  modelled  by  listing  each  of  the  object's 
fields,  methods,  and  procedures. 


DEFINITION  MODULE  Globals; 

FROM  RandMod  IMPORT  RandomObj; 
FROM  IOMod  IMPORT  StreamObj; 

TYPE 

PrecedenceType       =  (routine,  priority,  immediate,  flash); 
RadioType  =  (PRC77,  SINCGARS,  HF); 

UnitDesignationType  =  INTEGER; 
NetDesignationType  =  INTEGER; 

UnitLocationRec  =  RECORD 


location                 :  INTEGER; 

MemberNum      :  INTEGER; 

XCoord                :  REAL, 

YCoord                 :  REAL, 

END  RECORD; 

VAR 

BostUGenerator 

RandomObj; 

MainTrafGenerator 

RandomObj; 

InterstimGenerator 

RandomObj; 

NextTrafGenerator 

RandomObj; 

MEODurationGenerator 

RandomObj; 

AckDurationGenerator    : 

Rand 

omObj; 

MTBFGen 

Rand 

omObj; 

logFile 

:Stre 

amObj; 

ScenarioStopTime 

:  REAL; 

NumberOfReplications 

:INT 

EGER; 

SendOBETraffic 

:  BOOLEAN; 
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RadioFailure 

BOOLEAN; 

Modeljammer 
Number  AllowedRetries 

:  BOOLEAN; 
:  INTEGER; 

MEODurationVariability               :  REAL; 
MeanAcknowledgementTime     :  REAL; 
AckDuration Variability                 :  REAL; 
TimeBetweenFreqChanges        :  REAL; 
MaxRetrialsInNet                            :  INTEGER; 

SingarsEntryTime 
PRC77EntryTime 

:REAL; 
:  REAL; 

PRCCallingSingarsEntryTime  :  REAL; 

PROCEDURE  SetUpGlobals; 
END  MODULE. 

{ } 

DEFINITION  MODULE  Unit; 

{ } 

FROM  Globals  IMPORT  UnitLocationRec, 

NetDesignationType, 

UnitDesignationType; 
FROM  Radio    IMPORT  RadioObj; 
FROM  Bostlnf  IMPORT  BostlnstanceTxObj, 

BostlnstanceRecType, 

BoundUnitRecType; 
FROM  Bost     IMPORT  MEORecType; 

FROM  RecLL  IMPORT  LinkedListOfRecords; 

TYPE 

EchelonType  =  (Sldr,  Pit,  Co,  Bn,  Rgt,  Div,  Corps,  Army,  Country); 
CommunicationMethodType  =  (RadioComm,  Messenger); 
ReceiptStatusType  =  (NewMessage,  InterruptedMessage); 
CommMethArray  =  ARRAY  INTEGER  OF  CommunicationMethodType; 
RadioListType  =  ARRAY  INTEGER  OF  INTEGER; 

UnitObj  =  OBJECT 

name         :  STRING; 
unitType     :  UnitDesignationType; 
loc  :  UnitLocationRec; 

echelon      :  EchelonType; 
division     :  INTEGER; 
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regiment     :  INTEGER; 

battalion    :  INTEGER; 

company      :  INTEGER; 

platoon      :  INTEGER; 

numRadios    :  INTEGER; 

radio        :  ARRAY  INTEGER  OF  RadioObj; 

netType      :  ARRAY  INTEGER  OF  NetDesignationType; 

ASK  METHOD  Objlnit; 

TELL  METHOD  ReceiveBostlnstance 

(IN  IncomingBostPack :  BostlnstanceTxObj; 

IN  IntendedReceiver :  INTEGER; 

IN  SelectedRadio     :  RadioObj; 

IN  ReceiptStatus     :  ReceiptStatusType); 

TELL  METHOD  ExceptionHandlingRoute 

(IN  IncomingBostPack :  BostlnstanceTxObj); 

TELL  METHOD  KnowAboutJamming(IN  Radio  :  RadioObj; 

IN  Index :  INTEGER); 
END  OBJECT; 

UnitLocationListRecType  =  RECORD 

Unit :  UnitObj; 
END  RECORD; 

{ } 

DEFINITION  MODULE  Net; 

{ } 

FROM  Radio    IMPORT  RadioObj; 
FROM  Globals  IMPORT  RadioType, 
NetDesignationType, 

UnitLocationRec, 

PrecedenceType; 
FROM  Unit      IMPORT  UnitObj; 
FROM  Bostlnf  IMPORT  BoundUnitRecType; 
FROM  RandMod  IMPORT  RandomObj; 
FROM  RecLL    IMPORT  LinkedListOfRecords; 

TYPE 

WaitingListType  =  ARRAY  INTEGER  OF  RadioObj; 
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TransmissionCompletionResult  = 
(TransmitterFailed, 
Transmitterjammed, 

Receiverjammed, 
ReceiverOutOfRange, 
ReceiverFailed, 
SuccessfulContact); 

RadioNetRecType  =  RECORD 

Radio  :  RadioObj; 
Unit  :  UnitObj; 
Radiolndex  :  INTEGER; 
END  RECORD; 

IntendedReceiverRec  =  RECORD 

UnitLocRec  :  UnitLocationRec; 
RadioNetRec  :  RadioNetRecType; 
IntendedReceiverNumber  :  INTEGER; 
Condition  :  TransmissionCompletionResult; 
END  RECORD; 

NetObj  =  OBJECT 

NetDescriptor        :  STRING; 
Netlndex  :  INTEGER; 

Frequency    -        :  REAL; 
PropagateMode        :  STRING; 
Equipment  :  RadioType; 

AntennaType  :  STRING; 

PowerLevel  :  STRING; 

Netldle  :  BOOLEAN; 

Netjammed  :  BOOLEAN; 

Type  :  NetDesignationType; 

RadioList  :  LinkedListOfRecords; 

ASK  METHOD  Objlnit; 

TELL  METHOD  EnterNet(IN  subscriberRadio  :  RadioObj; 

IN  subscriberUnit  :  UnitObj; 

IN  subscriberRadioIndex :  INTEGER); 
TELL  METHOD  ChangeFreq; 

TELL  METHOD  ExecuteBusyPeriod; 

ASK  METHOD  Becomejammed; 
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ASK  METHOD  BecomeUnJammed; 

ASK  METHOD  UnitOnNet(IN  Unit  :  UnitObj; 
OUT  OnTheNet :  BOOLEAN; 
OUT  Active :  BOOLEAN); 

PRIVATE 

MeanAckTime  :  REAL; 

SelectedRadio  :  RadioObj; 

ASK  METHOD  NextTraffic(OUT  SelectedRadio  :  RadioObj); 
ASK  METHOD  ConstructWaitingList 

(OUT  WaitingList :  WaitingListType; 

OUT  NumberlnWaitingList  :  INTEGER; 
IN  HighestPrecedenceSought :  PrecedenceType; 
OUT  HighestPrecedenceFound  :  PrecedenceType; 
IN  TestAvailable  :  BOOLEAN); 

ASK  METHOD  SelectRadio(IN  WaitingList :  WaitingListType; 
IN  NumberlnWaitingList :  INTEGER; 
OUT  RadioChosen :  RadioObj); 

ASK  METHOD  CollectlntendedReceivers 
(IN  BoundUnitRec  :  BoundUnitRecType; 
INOUT  IntendedReceiverList :  LinkedListOfRecords); 

TELL  METHOD  AcknowledgementDelay 

(IN  IntendedReceiver  :  IntendedReceiverRec); 

TELL  METHOD  TransmissionDelay  (IN  IntendedReceiverList : 

LinkedListOfRecords; 
IN  MeanTransmissionTime  :  REAL); 

END  OBJECT; 

{ } 

VAR 

NetMasterList :  ARRAY  INTEGER  OF  NetObj; 
NumberOfNets  :  INTEGER; 
FreqGen       :  RandomObj; 

(  stuff  that  facilitates  I/O  and  Objinit  of  a  Net } 

IOWhatNetType  :  NetDesignationType; 
IOEquip :  RadioType; 
IONetDescriptor  :  STRING; 
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IONetlndex  :  INTEGER; 
END  MODULE. 

( } 

DEFINITION  MODULE  Radio; 

FROM  Globals  IMPORT  UnitLocationRec, 

NetDesignationType, 
RadioType; 
FROM  GrpMod  IMPORT  RankedObj; 
FROM  Bostlnf  IMPORT  BostlnstanceTxObj; 
FROM  StatMod  IMPORT  SINTEGER,TSINTEGER; 
FROM  RandMod  IMPORT  RandomObj; 

TYPE 

BostQueue  =  OBJECT(RankedObj) 
OVERRIDE 

ASK  METHOD  Rank(IN  a,  b  :  ANYOBJ)  :  INTEGER; 
END  OBJECT; 

RadioObj  =  OBJECT 


unitLoc 

:  UnitLocationRec; 

NetType 

:  NetDesignationType; 

netlndex 

:  INTEGER; 

Equipment 

:  RadioType; 

queue 

:  BostQueue; 

Available 

:  BOOLEAN; 

{strictly  mechanical} 

Jammed 

:  BOOLEAN; 

{being  interfered  with) 

Transmitting 

:  BOOLEAN; 

Receiving 

:  BOOLEAN; 

MTBF 

:REAL; 

NumlnQ 

:  TSINTEGER; 

NumMessAtt 

:  SINTEGER; 

NumMessComp 

:  SINTEGER; 

ASK  METHOD  Objlnit; 

ASK  METHOD  GETNetNum(IN  i  :  INTEGER); 

ASK  METHOD  GETUnitLocRec(IN  ULR  :  UnitLocationRec); 

ASK  METHOD  RequestTransmission 

(IN  BostTransferPack :  BostlnstanceTxObp; 
ASK  METHOD  SubmitBost 

(OUT  BostTransferPack :  BostlnstanceTxObj); 
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ASK  METHOD  CleanQueue; 

ASK  METHOD  IncAttempts; 

ASK  METHOD  IncCompletions; 

ASK  METHOD  DecCompletions; 

ASK  METHOD  Becomejammed; 

TELL  METHOD  BecomeUnJammed; 

ASK  METHOD  StartTransmitting; 

ASK  METHOD  StopTransmitting; 

ASK  METHOD  StartReceiving; 

ASK  METHOD  StopReceiving; 

TELL  METHOD  GenReliabilityFail; 

ASK  METHOD  FixNetIndex(IN  Netlndex  :  INTEGER); 

END  OBJECT; 

PROCEDURE  GetMTBF(IN  Radio  :  RadioObj;  OUT  MTBF  :  REAL); 

END  MODULE. 


{ } 

DEFINITION  MODULE  Message; 
{ } 

TYPE 

MessageOb  j  =  OBJECT; 

Descriptor    :  STRING; 

Duration      :  REAL; 

ASK  METHOD  Objlnit; 
END  OBJECT; 

VAR 

NumberOfMessages  :  INTEGER; 

MessageList  :  ARRAY  INTEGER  OF  MessageObj; 

IODuration  :  REAL; 

IOMessDescriptor     :  STRING; 

END  MODULE. 

{ } 

DEFINITION  MODULE  Traf  Gen; 

{ } 

TYPE 
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TrafficGeneratorObj  =  OBJECT 
SumOf AllRates      :  REAL; 
Pace  :  REAL; 

Alpha  :  REAL;     {Alpha  controls  the  slope  of  the  failure  rate  of  the 

overall  interstimulation  times.} 
MaxStimulationEpochs  :  INTEGER;    {Maximum  number  of  TrafGen  loops.} 

ASK  METHOD  Objlnit; 

TELL  METHOD  GenerateTraffic; 

ASK  METHOD  AddToRates(IN  Rate  :  REAL); 

ASK  METHOD  ChangePace(IN  NewPace  :  REAL); 


END  OBJECT; 
VAR 

TrafficGenerator  :  TrafficGeneratorObj; 

{ vars  used  to  facilitate  IO  and  OBJINIT- 

IO Alpha                 :  REAL; 
IOInitialPace         :  REAL; 

IOMaxEpochs 

:  INTEGER; 

PROCEDURE  SetUpTrafficGenerator; 
END  MODULE. 

{ } 

DEFINITION  MODULE  Penalty; 
{ } 

FROM  IOMod  IMPORT  StreamObj; 
TYPE 

Penalty  Record  =  RECORD; 

Time  :  REAL; 

PenaltyLevel       :  REAL; 

Penaltyjump        :  REAL; 

PenaltyRate        :  REAL; 

NextPenaltyRecord  :  PenaltyRecord; 
END  RECORD; 

PenaltyAccumObj  =  OBJECT; 
P  :  PenaltyRecord; 

PenaltyDumpFile  :  StreamObj; 


} 


141 


ASK  METHOD  Objlnit; 

TELL  METHOD  DeletePenalty(IN  Penalty  :  REAL; 

IN  Rate     :  REAL); 

TELL  METHOD  AddPenaltyON  Penalty  :  REAL; 

IN  Rate     :  REAL); 

ASK  METHOD  UsePenaltyFile(IN  FileName  :  STRING); 
ASK  METHOD  TidyAndReset; 

END  OBJECT; 
VAR 

Penalty Accum  :  Penalty AccumObj; 
END  MODULE. 


{ } 

DEFINITION  MODULE  Jammer; 

{ } 

FROM  Unit    IMPORT  UnitObj; 
FROM  RandMod  IMPORT  RandomObj; 


TYPE 

JammerOb  j  =  ( 

DBJECT 

Name 

:   STRING; 

IDNumber 

:  INTEGER; 

XCoord 

:  REAL; 

YCoord 

:  REAL; 

MaxPower 

:  REAL; 

AntennaHt 

:  REAL; 

AntennaGn 

:  REAL; 

BeamWidth 

:  REAL; 

Range 

:  REAL; 
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JamBandLow  :  REAL; 

JBandWidth  :  REAL; 

Active  :  BOOLEAN; 

NumAttempts  :  INTEGER; 

Numjammed  :  INTEGER; 

ASK  METHOD  Objlnit; 

TELL  METHOD  Jam  (IN  CurrentUnit :  UnitObj); 

END  OBJECT; 

VAR 
JammerMasterList  :   ARRAY  INTEGER  OF  JammerObj; 
JFreqGen  :  RandomObj; 

IOName        :  STRING; 
IONumber      :  INTEGER; 
IOXCoord      :  REAL; 
IOYCoord      :  REAL; 
IOMaxPower    :  REAL; 
IOAntennaHt :  REAL; 
IORange      :  REAL; 
IOActive     :  BOOLEAN; 

PROCEDURE  Readjammer; 

PROCEDURE  SelectTgt(IN  Jammer  :  JammerObj); 

PROCEDURE  CalcDistdN  A  :  JammerObj ;  IN  B  :  UnitObj) :  REAL; 

END  MODULE. 

{ } 

DEFINITION  MODULE  Bost; 

{ } 

FROM  Globals  IMPORT    UnitDesignationType, 
NetDesignationType, 
PrecedenceType, 
UnitLocationRec; 

TYPE 

{ } 

{ static  Bost  data  structures } 

{ } 


MEOReceiverRecType  =  RECORD 
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UnitType  :  UnitDesignationType; 
NTextMEO  :  INTEGER; 
SameAsSenderNumber  :  INTEGER; 
END  RECORD; 

MEOReceiverRecArray  =  ARRAY  INTEGER  OF  MEOReceiverRecType; 
PrecConstrArray  =  ARRAY  INTEGER  OF  INTEGER; 

MEORecType  =  RECORD 

NumConstrMEOs  :  INTEGER; 

PrecConstrMEO :  PrecConstrArray; 

MessageNumber  :  INTEGER; 

NumberOfReceivers  :  INTEGER; 

MEOReceiver  :  MEOReceiverRecArray; 

Net :  NetDesignationType; 

Broadcast :  BOOLEAN; 
END  RECORD; 
{ unit  connection  stuff } 


BostUnitConnRec  =  RECORD 

nextConnectionRecord  :  BostUnitConnRec; 
rateOfOccurance       :  REAL; 
unit  :  UnitLocationRec; 

END  RECORD; 

{ end  unit  connection  stuff 


BostMasterType  =  OBJECT 

Descriptor :  STRING; 

Precedence :  PrecedenceType; 

AllotedTime  :  REAL; 

OneTimePenalty:  REAL; 

PenaltyRate :  REAL; 

Perishable :  BOOLEAN; 

PerishabilityPoint :  REAL; 

NumberOfMEOs  :  INTEGER; 

MEO  :  ARRAY  INTEGER  OF  MEORecType; 

FirstUnitConnection  :  BostUnitConnRec; 

LastUnitConnection  :  BostUnitConnRec; 
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SumOfRates  :  REAL; 


ASK  METHOD  Objlnit; 

ASK  METHOD  GETMEO(IN  MEORec  :  MEORecType; 

IN  Number :  INTEGER); 
ASK  METHOD  ConnectToUnit(IN  connectingUnit  :  UnitLocationRec; 

IN  rate  :  REAL   ); 

ASK  METHOD  SelectUnit(OUT  UnitSelected  :  ANYOBJ  {UnitObj}); 

ASK  METHOD  GenerateOccurance; 
END  OBJECT; 

{ } 

VAR 

NumberOfBostMasterRecords  :  INTEGER; 
BostMasterList :  ARRAY  INTEGER  OF  BostMasterType; 
IODescriptor  :  STRING; 
IOPrecedence :  PrecedenceType; 
IOAllotedTime  :  REAL; 
IOOneTimePenalty:  REAL; 
IOPenaltyRate  :  REAL; 
IOPerishable :  BOOLEAN; 
IOPerishabilityPoint :  REAL; 
IONumberOfMEOs :  INTEGER; 
END  MODULE. 


{ } 

DEFINITION  MODULE  Bost; 
{ } 

FROM  Globals  IMPORT    UnitDesignationType, 
NetDesignationType, 
PrecedenceType, 
UnitLocationRec; 
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TYPE 

{ 

{ 

{ 


-static  Bost  data  structures- 


MEOReceiverRecType  =  RECORD 

UnitType  :  UnitDesignationType; 

NextMEO  :  INTEGER; 

SameAsSenderNumber  :  INTEGER; 
END  RECORD; 

MEOReceiverRecArray  =  ARRAY  INTEGER  OF  MEOReceiverRecType; 
PrecConstrArray  =  ARRAY  INTEGER  OF  INTEGER; 


MEORecType  =  RECORD 

NumConstrMEOs 

PrecConstrMEO 

MessageNumber 

NumberOfReceivers 

MEOReceiver 

Net 

Broadcast 
END  RECORD; 


:  INTEGER; 
:  PrecConstrArray; 
:  INTEGER; 
:  INTEGER; 
:  MEOReceiverRecArray; 

:  NetDesignationType; 

:  BOOLEAN; 


(- 


-unit  connection  stuff- 


BostUnitConnRec  =  RECORD 

nextConnectionRecord  :  BostUnitConnRec; 

rateOfOccurance       :  REAL; 

unit  :  UnitLocationRec; 

END  RECORD; 


{- 


;nd  unit  connection  stuff- 


BostMasterType  =  OBJECT 


Descriptor 

Precedence 

AllotedTime 

OneTimePenalty 

Penalty  Rate 

Perishable 

PerishabilityPoint 

NumberOfMEOs 


:  STRING; 
:  PrecedenceType; 
:REAL; 

:  REAL; 
:REAL; 

:  BOOLEAN; 

:REAL; 

:  INTEGER; 
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MEO  :  ARRAY  INTEGER  OF  MEORecType; 

FirstUnitConnection  :  BostUnitConnRec; 

LastUnitConnection  :  BostUnitConnRec; 

SumOfRates  :  REAL; 

ASK  METHOD  Objlnit; 

ASK  METHOD  GETMEO(IN  MEORec  :  MEORecType; 

IN  Number  :  INTEGER); 
ASK  METHOD  ConnectToUnit(IN  connectingUnit  :  UnitLocationRec; 

IN  rate  :  REAL    ); 

ASK  METHOD  SelectUnit(OUT  UnitSelected  :  ANYOBJ  {UnitObj}); 
ASK  METHOD  GenerateOccurance; 

END  OBJECT; 


VAR 
{ } 

NumberOfBostMasterRecords  :  INTEGER; 

BostMasterList :  ARRAY  INTEGER  OF  BostMasterType; 

IODescriptor  :  STRING; 

IOPrecedence :  PrecedenceType; 

IOAllotedTime  :  REAL; 

IOOneTimePenalty:  REAL; 

IOPenaltyRate  :  REAL; 

IOPerishable :  BOOLEAN; 

IOPerishabilityPoint :  REAL; 

IONumberOfMEOs  :  INTEGER; 

END  MODULE. 

{ } 

DEFINITION  MODULE  Route; 
{ } 


FROM  Globals  IMPORT  UnitLocationRec, 
NetDesignationType, 
logFile; 
FROM  Bostlnf  IMPORT  BostlnstanceRecType, 

BostlnstanceTxObj, 

BoundUnitRecType; 
FROM  Bost     IMPORT  MEORecType; 
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FROM  Radio  IMPORT  RadioObj; 
FROM  Unit  IMPORT  UnitObj, 

RadioListType, 

CommMetnArray; 
TYPE 
{ } 

PROCEDURE  RouteON  BostTxPack     :  BostlnstanceTxObj; 
IN  NewMEORec      :  MEORecType; 

IN  InstanceRec    :  BostlnstanceRecType; 

IN  SenderUnit    :  UnitObj; 

OUT  BoundUnitRec  :  BoundUnitRecType; 

OUT  RadioList     :  RadioListType; 

OUT  WalkOrTalk    :  CommMethArray); 

{ } 

END  MODULE. 
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APPENDIX  B.  EXAMPLE  IMPLEMENTATION  MODULE 

One  MCCAAM  implementation  module  is  provided  for  the  curious 

reader  to  see  how  an  object's  methods  are  coded.    The  Jammer  Object  has 

several  of  the  major  methods  in  the  simulation  program  and  are  detailed 

below: 

IMPLEMENTATION   MODULE  Jammer; 

FROM  IOMod      IMPORT  StreamObj,FileUseType(Input); 

FROM  MathMod  IMPORT  SQRT,  POWER; 

FROM  Globals     IMPORT  UnitLocationRec,  ALL  RadioType,ScenarioStopTime; 

FROM  Radio        IMPORT  RadioObj; 

FROM  Net  IMPORT  RadioNetRecType,NetObj,  NetMasterList; 

FROM  Unit  IMPORT  UnitObj,LocatioriList,UnitLocationListRecType; 

FROM  SimMod    IMPORT  Intermpt,SimTime; 

FROM  RandMod  IMPORT  RandomObj; 

FROM  RecLL       IMPORT  LinkedListOfRecords; 

PROCEDURE  Readjammer; 
VAR 

JamFile         :  StreamObj; 

i,NumJammers   :  INTEGER; 

Garbage         :  STRING; 

Jammer  :  JammerObj; 

BEGIN 

NEW(JamFile); 

ASK  JamFile  TO  Open( "jammer.dat", Input); 

ASK  JamFile  TO  Readlnt(NumJammers); 

NEW(JammerMasterList,  l..NumJammers); 

FOR  i  :=  1  TO  NumJammers 
ASK  JamFile  TO  ReadString(IOName); 
ASK  JamFile  TO  ReadInt(IONumber); 
ASK  JamFile  TO  ReadReal(IOXCoord); 
ASK  JamFile  TO  ReadReal  (IOYCoord); 
ASK  JamFile  TO  ReadReal(IORange); 

NEW(JammerMasterList[i]); 
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Jammer  :=  JammerMasterList[i]; 
SelectTgt(  Jammer) ; 
END  FOR; 
END  PROCEDURE; 

{  } 

PROCEDURE  CalcDist  (IN  A  :  JammerObj  ;  IN  B  :  UnitObj)    :  REAL; 

{  } 

VAR 

XDIST,  YDIST  :  REAL; 
BEGIN 

XDIST  :=  ABS(A.XCoord  -  (ASK  B  loc.XCoord)); 

YDIST  :=  ABS(A.YCoord  -  (ASK  B  loc.YCoord)); 

RETURN  (SQRT(POWER(XDIST,2.0)  +  POWER(YDIST,2.0))*100.0); 
END  PROCEDURE; 

{  } 

PROCEDURE  SelectTgtQN  Jammer  :  JammerObj); 

{  } 

VAR 
Dist  :  REAL; 

CurrentUnit      :  UnitObj; 
LocationListRec  :  UnitLocationListRecType; 
i  :  INTEGER; 

NumberOfLocations  :  INTEGER; 
FirstLLObject    :  LinkedListOfRecords; 

BEGIN 
i:=l; 

NumberOfLocations  :=  HIGH(LocationList); 
OUTPUTfHigh  LocList  is  :  \HIGH(LocationList)); 

WHILE  (i  <=  NumberOfLocations) 

IF  LocationList[i]  o  NILOBJ 

LocationListRec  :=  ASK  LocationList[i]  First(); 
ELSE 

OUTPUT("&&&&&&&&&&&    i  value  for  jammer  prob  is  :",  i); 
END  IF; 

WHILE  LocationListRec  o  NILREC 
CurrentUnit  :=  LocationListRec  .Unit; 
Dist  :=  CalcDist(Jammer,  CurrentUnit); 
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{Check  to  ensure  distance  is  being  calculated  correctly} 
IF  FALSE 
OUTPUTS"  *************************"  v 

OUTPUTfDistance  from  ",ASK  CurrentUnit  name,"  to  "); 
OUTPUT(ASK  Jammer  Name,  "  is  the  following  :   ",  Dist); 
OUTPUT; 
END  IF; 

IF  Dist  <  (ASK  Jammer  Range) 

IF  TRUE 

ASK  TraceStream  TO  WriteString( "About  to  jam  a  unit"); 

ASK  TraceStream  TO  WriteLn; 

END  IF; 

TELL  Jammer  TO  Jam(CurrentUnit); 
END  IF; 
LocationListRec  :=  ASK  LocationListfi]  Next(LocationListRec); 
END  WHILE; 
i  :=i+  1; 
END  WHILE; 
END  PROCEDURE; 


OBJECT  JammerObj; 


{-- } 

ASK  METHOD  Objlnit; 

{  } 

BEGIN 
Name  :=  IOName; 

IDNumber        :=  IONumber; 
XCoord  :=  IOXCoord; 

YCoord  :=  IOYCoord; 

MaxPower        :=  IOMaxPower; 
AntennaHt       :=  IOAntennaHt; 
AntennaGn       :=  IOAntennaGn; 
BeamWidth      :=  IOBeamWidth; 
Range  :=  IORange; 

Active  :=  TRUE; 

NumAttempts    :=  0; 
NumJammed       :=  0; 
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JB  and  Width      :=  40.0;     {  can  move  this  to  ReadJammer  } 
NEW(JFreqGen); 
END  METHOD; 


{  } 

TELL  METHOD  Jam(IN  CurrentUnit  :  UnitObj); 

{ } 

VAR 
CurrentRadio  :  RadioObj; 
CurrentNet      :  NetObj; 
RadioNet       :  NetObj; 
i  :  INTEGER; 

duration        :  REAL; 
RadioFreq       :  REAL; 


BEGIN 

INC(NumAttempts); 

duration  :=  20.0; 

JamBandLow   :=  ASK  JFreqGen  UniformReal(30.0,88.0); 

FOR  i  :=  1  TO  (ASK  CurrentUnit  numRadios) 
CASE  (ASK  CurrentUnit.radio[i]  Equipment) 
WHEN  PRC77: 
CurrentRadio  :=  ASK  CurrentUnit  radiofi]; 
CurrentNet     :=  NetMasterList[ASK  CurrentRadio  netlndex]; 
RadioFreq      :=  ASK  CurrentNet  Frequency; 
IF  CurrentRadio.Available 

OUTPUT("Jamming  an  available  PRC77..  if  in  correct  freq.  range 
&&&&&"); 

IF  (RadioFreq  >  JamBandLow)  AND  (RadioFreq  <  JamBandLow  + 
JBandWidth) 

ASK  CurrentRadio  TO  BecomeJammed; 

INC(NumJammed) ; 

RadioNet  :=  NetMasterList[ASK  CurrentRadio  netlndex]; 
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Interrupt(RadioNet,  "ExecuteBusyPeriod"); 

OUTPUTfJust  jammed  a  PRC-77  radio  for  following  unit:"); 
OUTPUT(ASK  CurrentUnit  name,"    ...on  this  net:     ",ASK  RadioNet 
NetDescriptor); 

OUTPUTC  ******************************************  ****"V 
OUTPUT; 

TELL  RadioNet  TO  ChangeFreq; 

TELL  CurrentRadio  TO  BecomeUnJammed  IN  duration; 
ELSE 

ASK  TraceStream  TO  WriteString("Didn't  jam  radio.. .freq.  not  in 
range"); 

ASK  TraceStream  TO  WriteLn; 
END  IF; 
ELSE 

OUTPUTf  Attempted  to  jam  an  unavailable  PRC-77"); 
OUTPUT; 
END  IF; 
WHEN  SINCGARS: 

OUTPUTfAttempted  to  jam  a  SINCGARS  Unit"); 
OTHERWISE 

OUTPUT(" Attempted  to  jam  an  HF  radio"); 
END  CASE; 
END  FOR; 

IF  (Active)  AND  (SimTime()  <  ScenarioStopTime  +  100.0) 

TELL  SELF  TO  Jam(CurrentUnit)  IN  (duration  +  60.0); 
END  IF; 

END  METHOD; 


END  OBJECT; 

END  {IMP}  MODULE  {Jammer}. 
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APPENDIX  C.  TIME-LATE  PENALTIES  FOR  BOSTS 

The  delay  in  performance  of  individual  Basic  Operational  SubTasks 
(BOSTs)  from  jamming  or  simply  because  of  traffic  may  have  differing  effects 
on  performance  of  the  Marine  Corps  missions  depending  upon  the  BOST. 
Delay  of  a  reporting  task  will  not  directly  cause  lives  to  be  lost  but  delay  to  a 
fire  mission  may.  Therefore  in  aggregating  total  delay,  the  minutes  of  delay 
should  be  given  differing  weights  in  calculating  a  communictions  measure  of 
effectiveness  based  on  timeliness.  This  appendix  describes  a  set  of  relative 
weights  or  penalties  for  each  of  the  BOSTs.  [Ref.  18] 

Before  describing  the  results  however,  it  is  noted  that  the  BOSTs  have 
been  partitioned  into  those  that  are  relevant  to  VHF  single-channel  nets  and 
those  that  are  not.  This  reduces  the  number  of  penalties  to  be  determined. 
The  BOSTs  not  considered  are  primarily  the  aviation  and  amphibious 
landing  BOSTs  that  are  performed  with  radios  of  other  frequencies  or  higher 
capacities  and  are  not  candidates  for  SINCGARs.  In  addition,  the  Combat 
Service  Support  (CSS)  BOSTs  are  not  considered   in  the  baseline  analysis. 

The  initial  set  of  penalties  for  the  SINCGARS  relevant  BOSTs  are  given 
in  the  accompanying  table,  Appendix  E.  They  were  estimated  by  relative 
judgments  of  the  research  team  with  a  base  penalty  of  100  for  the  standard  fire 
mission  BOST  under  the  call  for  force  MBOT.  Only  a  few  BOSTs  score  higher 
than  this.  In  general,  those  BOSTs  that  involve  execution  of  immediate  fires 
have  about  100  points  and  all  others  have  lower  penalties.  Coordination  of 
fire  BOSTs  have  the  next  highest  penalties,  followed  by  planning  and  finally 
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reporting  which  have  values  of  5  to  10  points.  This  leaves  room  for  combat 
service  support  BOSTs  to  be  added  at  a  later  date  if  desired. 

The  point  scheme  was  designed  to  give  an  order  of  magnitude  difference 
in  ratio  values  between  the  most  time  critical  and  least  time  critical  combat 
operations.  We  believe  the  order  of  penalties  would  not  significantly  vary 
between  individual  raters  although  the  penalty  ratio  might  vary. 

The  penalties  in  this  appendix  are  for  each  minute  of  delay  or  time  late. 
This  could  be  measured  from  either  initiation  of  the  BOST  or  from  some 
threshold  time  after  initiation  based  on  precedence  (i.e.  10  minutes  for 
FLASH  messages)  or  other  standard  operating  procedure  or  CEOI  thresholds. 
It  would  also  be  possible  to  extend  the  penalty  structure  to  include  a  one-time 
penalty  for  any  delay  above  a  threshold.  This  could  provide  additional 
discrimination  between  alternative  allocations  but  would  be  dependent  upon 
setting  an  acceptable  threshold,  which  may  be  difficult  to  establish.  If 
required,  the  one-time  penalties  could  be  established  as  a  multiple  of  the 
penalties  estimated  above.  The  size  of  the  multiple  could  be  the  same  for 
each  BOST  somewhere  in  the  range  of  a  multiple  of  10  to  100  or  could  vary  by 
BOST  category. 

An  additional  hierarchical  dimension  to  the  penalties  could  be  added  to 
reflect  relative  importance  of  the  BOSTs  as  a  function  of  whether  they  were 
initiated  by  the  platoon,  company,  battalion  or  brigade.  With  respect  to  fire 
mission  it  is  unlikely  that  there  is  any  difference  in  the  importance  of  the 
message  according  to  the  command  hierarchy.  However  for  planning 
messages  or  orders  it  can  be  argued  that  delay  moving  down  the  chain  of 
command  implies  that  many  more  units  will  be  affected  then  by  delay  at  the 
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bottom  of  the  chain.  Therefore  it  may  be  desirable  to  introduce  a  factor  to 
change  some  of  the  penalties  based  on  command  level.  At  this  time  the 
initiators  of  each  BOST  are  not  yet  specified  so  this  refinement  must  wait 
until  data  on  frequencies  of  initiation  of  BOSTs  by  command  level  are 
known.  It  is  likely  that  a  BOST  will  ordinarily  only  be  initiated  by  one  level 
of  command.  The  initial  set  of  penalties  are  shown  below  as  penalties  per 
minute  of  delay  from  initiation  of  the  BOST.  For  descriptions  of  the  listed 
BOSTs  (and  all  others),  see  [20]. 


# 

Name 

Preced. 

Allotted 

Penalty 

P.Rate 

Perish? 

P.Point 

1 

StdFireMission 

3 

63 

100 

3 

True 

120 

2 

DistGCEOrders 

3 

36 

10 

2 

True 

80 

3 

FinalProtFires 

4 

32 

150 

15 

True 

120 

4 

Intel.Report 

3 

24 

60 

0.5 

True 

120 

5 

CheckFire 

3 

15 

125 

10 

True 

30 

6 

HighAngleFire 

2 

64 

100 

5 

True 

130 

7 

HighBurstReg 

2 

40 

40 

0 

True 

80 

8 

PrecisionReg. 

2 

72 

40 

2 

True 

145 

9 

MortarMission 

3 

52 

25 

2 

True 

104 
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APPENDIX  D.  SIMULATION  SCENARIO 

Our  friendly  situation  is  intended  to  be  as  general  as  possible  and  still 
obtain  realism.  We  have  taken  the  notional  amphibious  MEB  depicted  in  the 
Marine  Air-ground  Task  Force  Presentation  Team  Pocket  Guide  of  1  October 
1990  to  be  our  base  MAGTF  for  this  analysis.  Based  on  guidance  from  the 
Warfighting  Center,  we  have  assumed  that  the  amphibious  operation  is  over 
and  the  MEB  is  in  conflict  ashore. 

In  order  to  provide  some  general  framework  in  which  to  organize  our 
notional  MEB  on  the  ground  and  provide  some  realistic  distance  calculations 
for  radio  and  jammer  ranges,  we  have  chosen  the  1:50,000  edition  3-DMA  of 
Twenty-Nine  Palms  West.  This  training  area  in  southern  California  is  one  of 
the  few  areas  in  the  Marine  Corps  that  see  large  units  rotate  through  for  live 
fire  and  force-on-force  exercises  on  a  continual  basis.  By  using  this  terrain  for 
our  analysis  example,  we  provide  the  Marine  Corps  analysts  with  a  common 
reference  point.  Additionally,  the  potential  exists  to  obtain  actual  exercise 
data  from  this  training  area  for  model  comparison. 

We  have  task  organized  the  Ground  Combat  Element  (GCE)  into  a 
reinforced  infantry  regiment  consisting  of  a  mechanized  infantry  battalion,  a 
normal  infantry  battalion,  a  heliborne  infantry  battalion,  a  direct  support 
artillery  battalion,  a  recon  company  and  a  light  armored  infantry  company. 
The  self  propelled  artillery  battery  has  been  attached  to  the  mechanized 
battalion  and  the  remainder  of  the  artillery  is  in  general  support.  We  have 
not  included  "Bravo"  or  alternate  command  groups  because  displacement 
(units  moving)  is  not  currently  included  in  the  model  and  because  adding 
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displacement  will  not  greatly  help  our  ability  to  distinguish  between  C3 
architectures. 

The  Direct  Air  Support  Center  (DASC)  is  co-located  with  the  regimental 
command  group,  and  the  remainder  of  the  Aviation  Combat  Element  (ACE) 
is  located  at  an  airstrip  several  miles  from  the  GCE. 

The  Combat  Service  Support  Element  (CSSE)  is  located  near  the  MEB 
headquarters.  Combat  Service  Support  Detachments  are  not  considered  close 
enough  to  the  maneuver  units  to  provide  alternate  routing  for  GCE  message 
traffic. 

This  task  organization,  including  unit  locations  is  depicted  here  in 
Appendix  D.  To  specify  a  high  but  realistic  level  of  activity  for  the  individual 
units,  we  have  adopted  the  following  general  scenario. 

The  heliborne  battalion  has  seized  its  objective  and  is  engaged  in  heavy 
combat.  The  battalion  reserve  has  been  committed,  so  all  three  companies  are 
engaged.  The  mechanized  battalion  was  moving  up  Gays  Pass  to  link  up  with 
the  heliborne  battalion  when  it  encountered  stiff  resistance.  It  is  also  heavily 
engaged  and  has  committed  its  reserve.  The  tank  company  and  all  three  rifle 
companies  are  engaged.  The  infantry  battalion,  which  was  following  in  trace 
of  the  mechanized  battalion  as  the  regimental  reserve,  has  reinforced  the 
mechanized  battalion  with  two  rifle  companies.  The  third  rifle  company  is 
now  the  regimental  reserve.  Thus,  we  have  a  tank  company  and  eight  rifle 
companies  engaged  in  combat  along  with  the  additional  units  illustrated  on 
the  following  page. 

The  purpose  of  detailing  a  general  scenario  like  the  above  is  to  motivate  a 
high  intensity  traffic  environment  and  provide  the  analyst  a  frame  of 
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reference  for  making  parameter  changes  with  respect  to  units,  jammers,  and 
their  locations.   Specific  unit  locations  used  are  listed  on  the  following  page. 
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Figure  23.  Example  Task  Organization 
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1:50,000  MCAGCC,  29  Palms  West  Edition  3-DMA 

1st  Marine  Expeditionary  Brigade 

Unit  Location 

1MEBCOC  (CE)  793  068 

MAG24     (ACE)  776  946 

BSSG1       (CSSE)  810  038 

IstSRIDet  532  276 

3DMarCOC(GCE)  608139 
3DMarFSCC 
3DMarDASC 

1/12FDC  (Arty)  600  086 

NBttry5/ll  (SP)  535186 

ABttryl/12  608  085 

BBttryl/12  588  083 

CBttryl/12  593  098 

ACo3DRecon  (CP  co-loc  w/Rgt)  608139 

lstPltCoa3dRecon  598  255 

2ndPltCoA3dRecon  522  201 

3dPltCoA3dRecon  574  271 

AColstLAIBn  475  218 

IstPltA/l/LAI  482  228 

2ndPltA/l/LAI  481218 

3dPltA/l/LAI  489  219 

lstBn3dMar  (COC,FSCC,HST,)  (Helo  Bn)  465  225 

lstPltCoA3dEngrBn  475  232 

ACol  /3  (CP,FAC,  81FO)  472  236 

l/3STADetl 

BCol  /3  (CP,FAC,  81FO)  478  230 

l/3STADet2 

CCol/3  (CP,  FAC,  81FO)  470  223 

l/3STADet3 

SectlBttryAlstLAAD  468  226 

3dMarTOWSectl  468  228 

ABttryl  /12FO  (w/BCo)  478  230 

HvyGunsl/3  472  240 
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81sPltl/3 
Dragonsl/3 


470  223 
472  240 


2ndBn3dMar  (COC,FSCC,HST) 
2ndPltCoA3dEngrBn 
AColstTanks  (ArtyFO,  81FO) 

IstPltCoA 

2ndPltCoA 

3dPltCoA 

TOWSquad 

ECo2/3   (CP,FAC,ArtyFO,  81FO) 
lstPltCoB3dTracks 
2/3STADetl 
NGFTeaml 


(Mech  Bn) 


538  187 
537  202 
545  205 

539  206 
545  208 
549  212 
545  204 

534  201 
534  202 
555  215 
534  201 


FCo2/3     546  200 

2ndPltCoB3dTracks 
2/3STADet2 

GCo2/3    551206 

3dPltCoB3dTracks 
81sPlt2/3 
HvyGuns2/3 
Dragons2/3 
3dMarTOWSect2 
Sect2BttryBl  stL  AAD 


545  201 

546  200 


550  207 
554  207 
534198 
534194 
542196 
539  189 


3dBn3dMar  (COC,FSCC,HST)  (Leg  Battalion) 
3dPltCoA3dEngrBn 

HCo3/3  (CP,FAC,ArtyFO,  81FO) 
lstPltCoC3dTracks 
NGFTeam2 
3/3STADetl 

ICo3/3      583  234 

2dPltCoC3dTracks 
3/3STADet2 


589  225 
581  235 

584  228 

583  230 

584  229 
584  228 


582  235 

583  234 
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KCo3/3    583  234 

3dPltCoC3dTracks  583  239 

81sPlt3/3  582  232 

HvyGuns3/3  584  240 

Dragons3/3  584  240 

3dMarTOWSect3  589  239 

SectlBttryClstLAAD  592  236 
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APPENDIX  E.  ANALYSIS  JAMMER  DATA 

The  table  below  lists  the  specific  values  for  the  two  jammer  objects  that 
were  modeled  in  the  analysis  example.  These  values  are  located  in  the 
"jammer.dat"  file  and  can  easily  be  changed  using  DB,  the  data  base 
manipulation  portion  of  MCCAAM.  Any  number  of  jammers  can  be 
modelled  to  produce  a  full  range  of  interference  for  an  architecture  of  interest. 
Only  two  jammers  were  modelled  for  our  analysis  example  since  we 
examined  such  a  small  portion  of  a  MEB  architecture. 

VALUE  DESCRIPTION 

2  Number  of  Jammers  in  File 

USSR.KwikJam  Jammer  Name 

1  ID  Number 

504.0  X  Coordinate 

240.0  Y  Coordinate 

5000.0  Range  (meters) 

30.0  Jam  Band  Width  Mhz 

60.0  Sector  Width  (degrees) 

15.0  Jamming  Duration  (mins) 

45.0  TimeBetween  Target  Selection  (mins) 

xyzjammer        Jammer  Name 

2  ID  Number 

555.0  X  Coordinate 

216.0  Y  Coordinate 

6000.0  Range  (meters) 

40.0  Jam  Band  Width  Mhz 

60.0  Sector  Width  (degrees) 

10.0  Jamming  Duration  (mins) 

45.0  TimeBetween  Target  Selection  (mins) 
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APPENDIX  F.  ANALYSIS  RUN  DATA 

The  table  below  lists  the  specific  values  for  the  global  variables  that  were 
used  in  the  analysis  example.  These  values  are  located  in  the  "c3run.dat"  file 
and  can  easily  be  changed  using  DB,  the  data  base  manipulation  portion  of 
MCCAAM. 


10000.00    Simulation  Horizon 
true    =  send  OBE  Traffic 

T    =  (T/F)  Do/Do  Not  model  radio  failures 
T    =  (T/F)  Do/ Do  Not  model  jamming 
1    =  #  replications 
2    =  #  of  allowed  retries  (in  queue) 
0.0000    =  MEO  duration  variability  in  (0,1) 

1.0000    =  Mean  Acknowledgement  Time 
0.0000    =  Acknowledgement  variability  in  (0,1) 
1440.00    =  time  (mins)  between  freq  changes 
8.00    =  time  (mins)  to  make  freq  changes 
2    =  max  retrials  by  a  net 
2.00    =  entry  time  for  SINCGARS 
1.00    =  entry  time  for  PRC-77 
1.00    =  entry  time  for  PRC-77  on  SINCGARS  net 
15.00    =  repair/replace  time  (mins)  for  PRC-77 
25.00    =  repair/replace  time  (mins)  for  SINCGARS 
60.00    =  jammer  sector  width  in  degrees 
5.00    =  MIJI  delay  time 

5.00    =  the  time  before  retrying  an  impossible  MEO 
F    =  the  graphic  presentation  of  the  penalty  process 
4000.00    =  PRC  mean  time  between  failures  (mins) 
16000.00    =  SINCGARS  mean  time  between  failures  (mins) 
4000.00    =  HF  mean  time  between  failures  (mins) 
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APPENDIX  G.  RADIO  ALLOCATIONS 

The  following  table  shows  how  the  different  types  of  radios  were 
distributed  for  each  of  the  four  allocation  schemes  used  in  the  analysis 
example: 

Key:  0  PRC-77  radios 
1  SINCGARS  radios 
2  HF  radios 


AS1 

AS2 

AS3 

AS4 

MEB  TAC 1 

0 

1 

0 

0 

MEB  Intel 

0     . 

2 

2 

2 

3DMAR  CMD 

0 

0 

0 

3DMAR  INTEL 

0 

1 

0 

0 

3DMAR  FSC 

0 

0 

1 

3DMAR  TAC 

0 

0 

0 

1/12  CMD 

0 

0 

0 

1/12  COF 

0 

0 

1 

1/12  FD 

0 

0 

0 

1/3  TAC  1 

0 

0 

1 

0 

2/3  TAC  1 

0 

0 

1 

0 

3/3  TAC  1 

0 

0 

1 

0 

A 1/12  COF 

0 

0 

1 

1 

B 1/12  COF  ' 

0 

0 

1 

1 

C 1/12  COF 

0 

0 

1 

1 

N  5/11  COF 

0 

0 

1 

1 

1/3  MORTAR 

0 

0 

1 

0 

2/3  MORTAR 

0 

0 

1 

0 

3/3  MORTAR 

0 

0 

1 

0 
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APPENDIX  H.  EXAMPLE  TRACE  FILE 

The  following  pages  give  an  example  of  the  MCCAAM  "c31og.out"  file 
which  was  essential  to  all  debugging  efforts.  By  carefully  placing  output 
statements  throughout  the  various  implementation  modules,  we  are  able  to 
track  individual  messages  as  they  route  through  different  nets. 

Simulation  Horizon  =      1000.000  time  units 

simulation  begins 

About  to  jam  a  unit 
About  to  jam  a  unit 
About  to  jam  a  unit 

NEW  BOST  STARTING 

getunit:  location  and  membernum  of  input      1      1 

asking  timer  to  experience  life 

***********  Just  Generated    StandardFireMission 

*  the  time  is  now  0.000000 

InterStimTime  is:   41.7434 

Didn't  jam  radio.. .freq.  not  in  range 

Didn't  jam  radio.. .freq.  not  in  range 


BtryFO  Receive  bosfc  this  unit's  loc.  =       1 
intended  receiver  number  is:         1 
MEONum  =  0 

bost  instance  descriptor  =  StandardFireMission 


getunit:  location  and  membernum  of  input      1      1 
getunit  location  and  membernum  of  input      1      1 
we  are  the  destination 
hi  from  route,  after  operating  on  sender 

\\\\\\\Point-to-Point  Comm/////// 
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finding  potential  receivers  for  MEO  Receiver  1 

receiver  is  a  new  player  for  this  bost 

net=      1 

Unit  attempting  send  is  BtryFO 

unit  type  AND  RECEIVER  NUMBER  3 

finding  potential  receivers  for  MEO  Receiver  2 

receiver  is  a  new  player  for  this  bost 

net=      1 

Unit  attempting  send  is  BtryFO 

unit  type  AND  RECEIVER  NUMBER  4 

Talking  for  receiver      1  on  radio      0 

BtryFO  Receive  bost:  this  unit's  loc.  =       1 
intended  receiver  number  is:         1 
MEONum  =  0 

bost  instance  descriptor  =  StandardFireMission 

Ghost  radio  in  receive  bost 
RadioList[I]  and  I  0  1 

cutting  out  of  receive  bost 

===========Enter  Net==========*==== 

this  net  is  DsArtyBnFd  number  2 

entering  unit  BtryFDC 

this  net  now  has  1  subscribers. 

===========EnterNet=============== 

this  net  is  BdeFSC  number  4 

entering  unit  BdeFSCC 
this  net  now  has  2  subscribers, 
unit  is  on  the  net  at  time  2.000000 


===========Enter  Net========= 

this  net  is  InfRegtTac  number 
entering  unit  RegtCoc 
this  net  now  has  2  subscribers, 
unit  is  on  the  net  at  time  2.000000 


===========Enter  Net========= 

this  net  is  InfRegtCmd  number 
entering  unit  BdeCOC 
this  net  now  has  2  subscribers, 
unit  is  on  the  net  at  time  2.000000 
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beginning  wait  for  perishable,  wait  is  5.0000 

THE  TIME  IS  NOW      15.000 

NEW  BOST  STARTING 


getunit:  location  and  membernum  of  input       1 

asking  timer  to  experience  life 

***********  Just  Generated    StandardFireMission 

*  the  time  is  now  41.743357 

InterStimTime  is:   37.9275 

BtryFO  Receive  bost:  this  unit's  loc.  =       1 
intended  receiver  number  is:         1 
MEONum  =  0 

bost  instance  descriptor  =  StandardFireMission 


getunit  location  and  membernum  of  input      1      1 
getunit:  location  and  membernum  of  input       1      1 
we  are  the  destination 
hi  from  route,  after  operating  on  sender 

\\\\\\\Point-to-Point  Comm/////// 

finding  potential  receivers  for  MEO  Receiver  1 

receiver  is  a  new  player  for  this  bost 

net=      1 

UT1      1 

UT1      2 

UT1      3 

Potential  receiver  BnFDC 

UT1      4 

Unique  receiver  determined,  receiver  is  BnFDC 

in      route 

the  RADIOLIST[I]  =  1 

the  net  used  to  transmit  =  1 

finding  potential  receivers  for  MEO  Receiver  2 

receiver  is  a  new  player  for  this  bost 

net=      1 

UT1      1 

UT1      2 

UT1      3 

UT1      4 
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Potential  receiver  BnFSCC 

Unique  receiver  determined,  receiver  is  BnFSCC 

in      route 

the  RADIOLIST[I]  =  1 

the  net  used  to  transmit  =  1 

Talking  for  receiver      1  on  radio      1 

Talking  for  receiver      2  on  radio      1 

requesting  that  the  bost  work  through  radio  1 

In  the  radio's  request  trans  trying  to  reach  net  #  1 

net  is  idle,  so  we  tell  it  to  xbp 

in  Execute  busy  period 

net  index  =  1 

MEONumToGo  =  1 

MEORec.MessageNumber  =  1 

getunit:  location  and  membernum  of  input      3     1 

getunit:  location  and  membernum  of  input      4     1 

0  th  trial  out  of  2  beginning 

IntendRec.IntendedReceiverNumber  is  1 

IntendRec.RadioNetRec.Unit  name  is  BnFDC 

ACKNOWLEDGEMENT  DELAY 

this  receiver  is  BnFDC 
netlndex  for  the  SelectedRadio  is  1 
condition  successful  contact 
IntendRec.IntendedReceiverNumber  is  2 
IntendRec.RadioNetRec.Unit  name  is  BnFSCC 

ACKNOWLEDGEMENT  DELAY 

this  receiver  is  BnFSCC 
netlndex  for  the  SelectedRadio  is  1 
condition  successful  contact 

TRANSMISSION  DELAY 

this  receiver  is  BnFDC  condition  for  receiver  1   is  SUCCESSFUL  CONTACT 
this  receiver  is  BnFSCC  condition  for  receiver  2  is  SUCCESSFUL  CONTACT 


BnFDC  Receive  bost:  this  unit's  loc.  =       3 
intended  receiver  number  is:         1 
MEONum  =  1 

bost  instance  descriptor  =  StandardFireMission 


getunit:  location  and  membernum  of  input      3     1 
getunit:  location  and  membernum  of  input      3     1 
we  are  the  destination 
meo  not  done  yet 
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APPENDIX  I.  LIST  OF  ABBREVIATIONS  AND  ACRONYMS 

AHP  Analytical  Hierarchy  Process 

BOST  Broad  Operational  Sub  Task 

C2FAC  Command  and  Control  Facility 

C4I2  Command,Control,Communications,Computers,  Intelligence 

CDB  Communications  Data  Base 

CSS  Combat  Service  Support 

DCT  Digital  Communications  Terminal 

DF  Direction  Finding 

DMA  Defense  Mapping  Agency 

ECAC  Electronic  Compatibility  Analysis  Center 

ECCM  Electronic  Counter-Counter  Measures 

ECM  Electronic  Counter  Measures 

ERF  Electronic  Remote  Fill 

EW  Electronic  Warfare 

FDC  Fire  Direction  Center 

FM  Frequency  Modulated 

FO  Forward  Observer 

FSCC  Fire  Support  Coordination  Center 

HF  High  Frequency 

MACCS  Marine  Air  Command  &  Control  System 

MAGTF  Marine  Air  Ground  Task  Force 

MAMES  Multiple  Agency  Message  Exchange  Occurrences 

MCCES  Marine  Corps  Communications  Electronics  School 

MCES  Modular  Command  &  Control  Evaluation  Structure 

MCTCA  Marine  Corps  Tactical  Communications  Architecture 

MEB  Marine  Expeditionary  Brigade 

MEF  Marine  Expeditionary  Force 

MEO  Message  Exchange  Occurrence 

MEU  Marine  Expeditionary  Unit 

MIRC  MAGTF  Interoperability  Requirements  Concepts 

MOE  Measure  of  Effectiveness 

MOP  Measure  of  Performance 

MOT  Maturity  Operational  Test 

MTACCS  Marine  Tactical  Command  and  Control  System 

O/A  Operational  Assessment 

OPFAC  Operational  Facility 

PLRS  Position,  Location,  Reporting  System 

RT  ReceiverAransmitter 

SCR  Single  Channel  Radio 

SINCGARS      Single  Channel  Ground  and  Airborne  Radio  System 

SNR  Signal  to  Noise  Ratio 

SOP  Standard  Operating  Procedure 
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TTDP  Technical  Interface  Design  Plan 

TM  Threat  Model 

TO  Table  of  Organization 

WFC  Warfighting  Center 
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